Hacker News new | past | comments | ask | show | jobs | submit login
RFC 9498 on the GNU Name System (rfc-editor.org)
142 points by stargrave 7 months ago | hide | past | favorite | 37 comments



A distributed naming system intended to work with mesh networks like GNUnet.

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.


Zooko's triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle You can't have it all.


Indeed that would work. In theory. Especially since we thought of that use case (delegation into DNS) with the GNS2DNS record type.

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.


Since the TLDs are multiplying with no end in sight, using a zone key seems smart.


Or, I guess, "someone" could apply for a custom gTLD and link it. Of course, that "someone" would need the $200K needed to review the application and all that stuff :P


Eh, you realize that this very work on the GNU Name System prompted IETF to create the ".alt" zone for this purpose already, minus the $200k fee? Registration is open at https://gana.gnunet.org/dot-alt/dot_alt.html


I'd settle for global and not human readable, if it means I get a domain I can use as a CNAME on a nicer domain.

Dynamic dns services are nice and all, but needing to pre-register gets kind of annoying.


It can't possibly work, if you want your nicer domain to be globally unique.

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.


If I understand they want a (globally unique, secure) GNS name and a (globally unique, human friendly) traditional DNS name which acts as an alias for the GNS name via CNAME.

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.


These are all valid deployment questions, which we tried to address in Appendix A.

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.


But what's the point? Federation, I suppose?

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.


TLS certs without having to buy a domain? Create a GNS domain, set a LEHO record with the necessary Host name, and make your cert based on that? Obviously you'll need a CA that's willing to issue certs for GNS LEHO names, but that way you can use the current TLS CA system to a domain without having to actually spend money on one. Alternatively, have the CA issue wildcard certs for zTLDs and then you can manage your own zTLD without issue.


Letsencrypt allows to produce TLS certificates for free, under a reasonable, globally trusted CA.

If we wanted to go away from centralization here, that would require a serious breakthrough, the magnitude of Bitcoin.


Sure but that's contingent on owning or being able to host something under a domain.


Would <UUID>.example.com not work? With first to register getting priority. Or <pubkey>.example.com with the corresponding private key needed to do updates.

The "nicer" domain I am referring to would be a normal domain from a registrar.


Note that this is in the Independent Submission stream, Informational category:

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


Which is the case for vast majority of RFCs.


Some clarification might help here.

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 correct. I would like to add that the ISE also had us engage with a variety of stakeholders within the IETF (dnsop, for example, as part of discussions on RFC 9476) and also expected some third party reviews.

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


Previous discussion of GNU Name System: https://news.ycombinator.com/item?id=32222360


I have mixed feelings. A unitary root of naming and the dns is a huge value proposition to walk away from. Fitting gnu names under .alt is only partly ameliorative.


I see it exactly the opposite way.

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.


...and do separate nation-wide namespaces? We have those already, and they're actually the main source of censorship, abusive seizure and oppression.

Also, whether there is one namespace root or many, we all still live in a single world.


Okay, you named some downsides of the unitary root. Now name the downsides of non-unitary roots.

Otherwise your proposal lacks the context to decide if it's a worthwhile tradeoff or not.


Momentum, random names and (possibly) higher latency. IIRC IPFS is particularly bad latency-wise but I'm not sure how much of that is name lookup vs file transfer, and that could be implementation specific. Name lookups are also very cacheable.


I think what's missing is that squatters and other bad actors are going to attack the distributed name system, too. It should be somehow resilient, and ideally resistant, against deliberate misuse by powerful parties. For instance, DoS attacks that pollute the namespace and could make the distributed naming service too slow or resource-intensive will necessarily be mounted.

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.)


> IPFS is particularly bad latency-wise I'm not sure how much of that is name lookup

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.


100%. I've been saying this for years.


Basically that means you have an issue with https://www.rfc-editor.org/rfc/rfc9476.html, not GNS.

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.


Has anyone been following along with what the plan is for GNS? An RFC is quite cool but are there any zones being distributed over GNS to play around with?


We are currently working on mirroring some DNS TLDs: https://www.gnunet.org/en/news/2022-11-NGI-Entrust-GNS-TLDs....

I have been a bit preoccupied with the RFC and other stuff recently, but its progressing.


Thanks! Big fan of the project, I've been following it for ages. Thanks for the hard work.


Cool! Seems similar to Handshake domains?


GNS seems not to replace the actual names like Handshake -- but just the protocol for distributing the names across the network. [1]

[1] https://news.ycombinator.com/item?id=32223129


[flagged]


There is nothing "toxic" about Stallman or GNU.


“GNU slash Linux”

Its a matter of personal opinion and perspective. I find their attitude generally to be toxic, even if it is just based in good ideals; how you communicate with others does matter.


Yep. In 2000 when I saw "GNU" in the name, I got mildly excited.

Now when I see it, I'm expecting it to be semi-abandoned and its developers to care more about ideology than about the technology.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: