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 <[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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
