RFC 9498 on the GNU Name System
rfc-editor.org
rfc-editor.org
GNS does not support names which are simultaneously global, secure and human-readable. Instead, names are either global and not human-readable or not globally unique and human-readable. In GNS, each user manages their own zones and can delegate subdomains to zones managed by other users.
For example, ICANN could just create 'DNS zone' that would embed DNS as a zone into GNS.
Dynamic dns services are nice and all, but needing to pre-register gets kind of annoying.
If you don't, it depends on how local your domain needs to be; maybe all you need is a record in /etc/hosts on your home router.
This can work, and sounds like a good compromise in that it lets machines and people who care deeply about security use your secure name (which is more portable than an IP address), while providing a human friendly name for people who don't care and just want things to work.
In a nutshell, we expect that resolvers would ship with a (large) set of default "suffix-to-zone" mappings, that can be overridden by the user to provide a usable and convenient out-of-the box experience. Not that "we expect" means that this would be the ideal scenario, not something to expect when installing our reference implementation right now.
Because if globally unique, human-readable DNS still works, I see no point in migrating off it. If the point is smoother migration, then we should start forgetting about human-readability, because it's going to disappear anyway.
If we wanted to go away from centralization here, that would require a serious breakthrough, the magnitude of Bitcoin.
The "nicer" domain I am referring to would be a normal domain from a registrar.
There is a BUT: You need an initial label for ICANN zone to resolve the names. Unless you have a resolver implementation that "hides" the zkey of ICANN in the UI. But technically, under the hood, a name for this ICANN zone would look like:
www.example.com.THEICANNZKEY...
ICANN could also publish the TLDs individually as zones, however, and you could have an "ICANN Start Zone" (see Start Zone in the RFC) consisting of the TLD/zone key mappings.
> This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
People usually think of RFCs as being the output of the IETF, and the IETF is the biggest contributor by far. Roughly half of the IETF's RFCs are standards or on what's called the "standards track" (most Internet standards are formally at the "Proposed Standard" rather than "Standard" level). The remainder have some other status such as "Informational".
However, there are also other entities that publish into the RFC Series, including the Internet Research Task Force (IRTF), and the Internet Architecture Board (IAB). In addition, there is what's called the Independent Stream, in which an appointed editor just determines what documents can be published. Importantly, this last category hasn't gone through the IETF consensus process: they're just something someone wanted to publish as an RFC and the Independent Series Editor agreed. GNU Name System falls into this category.
This is probably the time to thank and give credit to all reviewers and the ISE in particular, again :) https://www.rfc-editor.org/rfc/rfc9498.html#name-acknowledge...
Over time the unitary root of naming has attracted increasing levels of censorship, tracking, abusive seziure, and oppression.
The dream of a worldwide namespace has become a nightmare. Let's wake up.
Also, whether there is one namespace root or many, we all still live in a single world.
Otherwise your proposal lacks the context to decide if it's a worthwhile tradeoff or not.
This is one place where a significant proof of work, along the lines of Namecoin or handshake.org, would make sense. (Another place is password hashing, for example.)
All of that is due to their mistake of trying to use a sessionful protocol for their DHT.
Bittorrent got this right -- sessionless DHT -- which is why IPFS remains a rounding error compared to bittorrent, and will remain so until they adopt a sessionless DHT.
GNS, in theory, could replace DNS (the technology) and reuse its current root governance model as default.
From the point of view of GNS namespace governance is separate from name resolution protocols. Of course, from the point of view of a lot of DNS folks, DNS is both: The governance (ICANN) and the technology (RFC 1035 et al) and indivisible.
I have been a bit preoccupied with the RFC and other stuff recently, but its progressing.