Live data from Hacker News

RFC 9498 on the GNU Name System

rfc-editor.org

31–39 of 39 posts

Re: RFC 9498 on the GNU Name System

#31
post #23
post #14

Earlier quoted context omitted.

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 othe…

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

Re: RFC 9498 on the GNU Name System

#32
post #29
post #20

Earlier quoted context omitted.

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…

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.

Re: RFC 9498 on the GNU Name System

#33
post #19
post #18

Earlier quoted context omitted.

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.

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

Re: RFC 9498 on the GNU Name System

#34

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.

Re: RFC 9498 on the GNU Name System

#35
post #32
post #29

Earlier quoted context omitted.

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…

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.

Re: RFC 9498 on the GNU Name System

#36
post #32

Earlier quoted context omitted.

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 o…

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.

Re: RFC 9498 on the GNU Name System

#37
post #36

Earlier quoted context omitted.

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 o…

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.

Re: RFC 9498 on the GNU Name System

#38
post #19

Earlier quoted context omitted.

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.

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

Re: RFC 9498 on the GNU Name System

#39
post #20

Earlier quoted context omitted.

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.

Would .example.com not work? With first to register getting priority. Or .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.

Post reply on HN