Re: [GNUnet-developers] Goodbye ".gnu"

[Schanzenbach, Martin]

Hi,

I need two clarifications as this change basically broke everything ;)

1. API:
The GNS_lookup API call takes a zone to look up in. Previously tools looked up 
the "gns-master" for a sane default value.
This is no longer needed I guess??
If yes, we should remove it.

2. Proxy:
The proxy still uses gns-master for lookups. Now the question is if the 
application calling lookup should handle the TLD or of the resolver takes case 
of that automagically.  From your change in the CLI tool I assume the former?

BR
Martin

> On 3. Mar 2018, at 23:06, Christian Grothoff <address@hidden> wrote:
> 
> Dear all,
> 
> I've just pushed a significant change to GNS to master, which may affect
> some of you and I wanted to make sure you're not caught unaware.
> 
> Basically, I've removed the restriction that GNS is only responsible for
> ".gnu" and ".zkey". In fact, both of these TLDs are now gone from the
> code.   The motivation is 3-fold:
> 
> 1) IETF doesn't want us to use those, having rejected our draft for 4+
> years now, so clearly trying to play nice doesn't work.
> 
> 2) ".gnu" confused people. I expect that if you create a nickname
> "trump" and then start to map the ".trump" TLD will be way more intuitive.
> 
> 3) GNS shouldn't be just for ".gnu", we want to replace DNS after all.
> So this is a step towards liberating all the TLDs and refute Cerf's
> assertion that ICANN owns the global namespace.  Instead, from now on,
> GNS can just use _any_ TLD for which it is configured, overriding
> ICANN/IANA.
> 
> 
> So in the new scheme, your pseudonyms are your nicknames and also your
> TLDs.  If you create a nickname "de", GNS will take over ".de" and no
> longer resolve via IANA/DENIC. If you create a nickname "fr", well,
> goodbye AFNIC. The build-in ".pin" zone already takes over ".pin".
> 
> 
> Note that there are basically three types of TLD-hijacks:
> 
> 1) Your own zones take over the TLDs you specified for your pseudonym
> names.  The pseudonym is always published in the GNS records of the zone
> as a NICK record.  So merely by creating a GNS zone you will capture
> some gTLD on your own system, and that without paying 130k to ICANN! ;-)
> 
> 2) The "gns" configuration section can tell GNS to capture other TLDs,
> simply by having a value ".TLD" being assigned to the (base32-encoded)
> public key of a zone.  Note the dot (".") before TLD.  The default value
> for the ".pin" option provides you with a build-in example for such a
> configuration option.
> 
> 3) Any time a domain name ends in a valid base32-encoded public key, we
> assume it's for GNS (working like the old ".zkey", except without the
> ".zkey").
> 
> 
> I have made sure that the GNS tests pass, gnunet-namestore-gtk can
> handle the new semantics, and update the Texinfo manual. However, that
> does not mean that there is not _something_ somewhere broken by this
> change, so please do report if you experience any new issues.
> 
> 
> The next step will be to import existing ccTLD zones into GNS zones.
> Specifically, I'd like to create a demonstration that hijacks ".fr", as
> that zone is open data.  (We'd only go for the the ccTLD, for domains
> like inria.fr we can use GNS2DNS records to delegate to the respective
> DNS server of inria.fr.)
> 
> 
> Happy hacking!
> 
> Christian
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers


- Martin

GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

signature.asc
Description: Message signed with OpenPGP