> On 4. Mar 2018, at 13:56, Schanzenbach, Martin <[email protected]> > 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 <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > - Martin > > GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
- Martin GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
