[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
signature.asc
Description: Message signed with OpenPGP
- [GNUnet-developers] Goodbye ".gnu", Christian Grothoff, 2018/03/03
- Re: [GNUnet-developers] Goodbye ".gnu", Schanzenbach, Martin, 2018/03/04
- Re: [GNUnet-developers] Goodbye ".gnu", Christian Grothoff, 2018/03/04
- Re: [GNUnet-developers] Goodbye ".gnu", Schanzenbach, Martin, 2018/03/04
- Re: [GNUnet-developers] Goodbye ".gnu",
Schanzenbach, Martin <=
- Re: [GNUnet-developers] Goodbye ".gnu", Christian Grothoff, 2018/03/04
- Re: [GNUnet-developers] Goodbye ".gnu", Schanzenbach, Martin, 2018/03/04
Re: [GNUnet-developers] Goodbye ".gnu", carlo von lynX, 2018/03/04
Re: [GNUnet-developers] Goodbye ".gnu", Schanzenbach, Martin, 2018/03/05