gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Goodbye ".gnu"
Date: Sun, 4 Mar 2018 13:57:56 +0100


> On 4. Mar 2018, at 13:56, Schanzenbach, Martin <address@hidden> wrote:
> 
> 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?
This should obviously read "without a default namespace...".
> 
>> 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
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers


- Martin

GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]