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

[Schanzenbach, Martin]

Hi,

I have a few "concerns":

> On 3. Mar 2018, at 23:06, Christian Grothoff <address@hidden> wrote:
> 
> Dear all,
> 
> I've just pushed a significant change to GNS to master, which may affect
> some of you and I wanted to make sure you're not caught unaware.
> 
> Basically, I've removed the restriction that GNS is only responsible for
> ".gnu" and ".zkey". In fact, both of these TLDs are now gone from the
> code.   The motivation is 3-fold:
> 
> 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?

> 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?
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.
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.
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".

- 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").
> 
> 
> I have made sure that the GNS tests pass, gnunet-namestore-gtk can
> handle the new semantics, and update the Texinfo manual. However, that
> does not mean that there is not _something_ somewhere broken by this
> change, so please do report if you experience any new issues.
> 
> 
> The next step will be to import existing ccTLD zones into GNS zones.
> Specifically, I'd like to create a demonstration that hijacks ".fr", as
> that zone is open data.  (We'd only go for the the ccTLD, for domains
> like inria.fr we can use GNS2DNS records to delegate to the respective
> DNS server of inria.fr.)
> 
> 
> Happy hacking!
> 
> Christian
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers


- Martin

GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

signature.asc
Description: Message signed with OpenPGP