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

[Christian Grothoff]

On 03/04/2018 08:45 AM, Schanzenbach, Martin wrote:
>> 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.
>>
> So instead we now have an unlimited number of non-compliant TLDs?

I would say we give the users control over the entire namespace, not
just one TLD.

>> 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.
> 
> 
> As I understood the significant change is that GNS now initially determines 
> the "root" zone by checking the TLD against local egos, right?

That, and against the configuration file (see case (2) below).

> This is where you lost me. I would have expected the DENICs of the world to 
> still be the authorities over their TLD.
> However, if I must create a local ego and import all the data, _I_ manage the 
> zone. I don't want that.

That's not exactly the intended use-case. The intended use case is that
(1) you control .schanzen, and if you wanted also .martin.
(2) you _delegate_ control over say ".grothoff" to me, or ".pin" to the
pin zone.
(3) you _delegate_ control over '.de' to someone who is trustworthy to
operate the '.de' registry. That _could_ still be DENIC (if they decide
to support GNS), or it could be some hacker who decided to setup a DENIC
mirror (in the DHT, using GNS) matching the '.de'-zone.  This becomes
particularly interesting in cases where someone forces say '.cat' to
remove certain names, and then the hackers operating '.cat' in GNS
decide otherwise ;-).

> I liked the idea more of having a delegation to the authority within my own 
> TLD.
> I realize that I can still do that, but the primary use case you propose 
> eludes me.

Well, that is the primary use case. The secondary use case is to
delegate non-conflicting TLDs (which are not allocated by ICANN). And
then the *third* use-case is to enable migration away from DNS.

In particular, suppose we can convince AFNIC to publish ".fr" in GNS.
AFNIC would publish their PKEY, and then we would likely put that PKEY
into the default configuration (gns.conf.in) for '.fr'.

> Can't we just have the local label "" to be the local TLD that maps against 
> the "gns-master"?
> Then, "fr" is a PKEY delegation, either to a local ego (if I want to copy) or 
> a "friend".

I don't understand what you mean by local label.  Regardless, the
current setup has the advantage that there is no special "gns-master"
zone, and that all (local) zones are completely equal, which helps
usability (just from playing with it I can confirm that).

-Christian

> - Martin
> 
> 
>>
>>
>> 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").

signature.asc
Description: OpenPGP digital signature