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

[Schanzenbach, Martin]

I don't understand how you can delegate TLDs.
In GNUnet currently we have identities (=local namespaces).
As I understand it, those are now the TLDs handled locally via GNS.
How can I delegate a TLD to another entity such as "de"?
If I add a new identity called "de", then _I_ must populate that namespace. I 
cannot delegate it anymore.
With a default root namespace (formerly known as "gns-master"), what namespace 
would I use for delegation of the "de" TLD?

> On 4. Mar 2018, at 11:32, Christian Grothoff <address@hidden> wrote:
> 
> 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").
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers


- Martin

GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

signature.asc
Description: Message signed with OpenPGP