LWN: Comments on "RFC 9498: The GNU Name System"

RFC 9498: The GNU Name System

grawity — Thu, 30 Nov 2023 11:01:34 +0000

> Should there be a (restricted-access/back-channel) infrastructure between DNS and registrars?

There already is. When a registrar updates the 'nameserver' values for your domain, they use a restricted-access back-channel to whichever registry runs the respective TLD. (e.g. you get a .cz domain at Namecheap, and Namecheap sends a "foo.cz is hosted at us now" update to NIC.CZ over this back-channel.)

It seems you're thinking of the entire DNS 'system' as a single database with user accounts somewhere, though? That's not the case. Regular DNS updates are not submitted to 'the system'; they're submitted to some specific hosting provider that handles some specific domains.

So if you're using the free DNS hosting provided by your registrar, and you're making some regular DNS updates (changing IP addresses), there is no need for a back-channel "from registrar to DNS" because the registrar /itself/ is the 'DNS' – it just updates its own database and doesn't transmit anything anywhere further than that.

> 2FA seems to be nearly ubiquitous these days. Why isn't it part of the DNS system?

Because 2FA is used when authenticating to an 'active' system – a server that has user accounts (like a SQL database) and is able to verify your 2FA credential (which is usually one-time) – and DNS is not that kind of 'system'.

It's more of a passive 'system' in the same sense that the web is a system for publishing webpages, but you don't 2FA to your "web account" to publish a website, and likewise you don't 2FA to your "DNS account" to perform DNS updates – you authenticate to your Namecheap account, or to your personal BIND9 server, &c. (And those individual DNS hosting providers *do* have 2FA, most of the time.)

The equivalent of 2FA for passively published data would be digital signatures (e.g. PGP-signing a document), and DNS does have that – that's exactly what DNSSEC is.

> I should not be able to fake that 192.0.2.10 is in the blocks of addresses assigned to Google. Would such a system have the same vulnerabilities as DNS?

The issue is that "assigned to Google" does not necessarily mean "routed to Google". On a global scale, that's the problem that e.g. RPKI and BGPsec are trying to battle – obtaining a certificate for someone else's domain by BGP hijacking their IP prefix to your own server is already a known threat.

> Would Opportunistic Encryption (host2gateway » gateway2gateway » gateway2host) reduce the problem? (I know I connected to my gateway. My gateway knows it connected to the correct remote gateway. The remote gateway knows it connected to its correct internal host.)

How do you know it's the 'correct' gateway? Encryption is not a verification mechanism by itself – and that goes double for opportunistic encryption, which often specifically means "just encrypt even if there's no verification". Opportunistic encryption is a mechanism for improving privacy, not authenticity.

More importantly, a 'correct' gateway is not necessarily correct for that particular route; e.g. your ISP's gateway may legitimately be talking to Cogent's gateway and having the verified tunnel established, and Cogent may be legitimately talking to one of their customers' gateways, and that won't help in the slightest if the customer advertises the wrong prefix (by mistake or by malice) and Google's IP ranges get routed to them.

RFC 9498: The GNU Name System

Cyberax — Thu, 30 Nov 2023 08:11:16 +0000

> You can't hard-fail on that DNS query

I mean, you can. And with DoH/DoT it's pretty easy to do the query to work around broken ISPs.

Browsers also have a "bully pulpit" they can start with just silently ignoring DNSKEY query failures, then a couple years later start showing a banner like "your ISP is tampering with your DNS", then put the DNSKEY-failed connections behind the usual scary "certificate might be invalid" dialog.

> Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.

The same statement could be made about deprecating HTTP.

Especially since it has caused half of the Internet to depend on one _service_ (Let's Encrypt). Its failure will basically cause an Internet-wide blackout, all to prevent occasional malicious MITM.

DANE will eventually allow to break this dependency.

RFC 9498: The GNU Name System

fest3er — Thu, 30 Nov 2023 06:18:15 +0000

Hmmm. Are address registries (ARIN, APNIC, etc) trusted? Should there be a (restricted-access/back-channel) infrastructure between DNS and registrars? 2FA seems to be nearly ubiquitous these days. Why isn't it part of the DNS system?

Seems to me that part of the problem is verifying that an IP address has been (maybe statically) assigned to the entity claiming that address. While a miscreant might be able to fake controlling an FQDN, but she shouldn't be able to fake being the official assignee of the related address. For example, while I might be able to fake that I control the name 'google.com', I should not be able to fake that 192.0.2.10 is in the blocks of addresses assigned to Google. Would such a system have the same vulnerabilities as DNS?

Would Opportunistic Encryption (host2gateway » gateway2gateway » gateway2host) reduce the problem? (I know I connected to my gateway. My gateway knows it connected to the correct remote gateway. The remote gateway knows it connected to its correct internal host.) Or does it still boil down to "Exactly who are we to trust?"

RFC 9498: The GNU Name System

NYKevin — Thu, 30 Nov 2023 00:47:10 +0000

> 1. A legacy CA certificate without stapled DANE. The browser will have to do a DNSSEC-secured query to verify that there is no DANE record for this domain name. A browser can cache the outcome ("no DANE record, verified via DNSSEC") for a reasonable time.

And *that* is why the stapling proposal fell apart. You can't hard-fail on that DNS query, because some ISPs will not serve it correctly and you would display a spurious warning. Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.

RFC 9498: The GNU Name System

NYKevin — Thu, 30 Nov 2023 00:34:44 +0000

You can do that with DNS already. Just use some alt root and you're off to the races.

Disclaimer: IANA hates this.

RFC 9498: The GNU Name System

Cyberax — Mon, 27 Nov 2023 18:46:52 +0000

> Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."

That's not true. We have plenty of technologies that "sometimes" work, but being in a browser slowly pushes them to work everywhere. Example: WebRTC.

> Presumably, this is restrictive DANE. Your threat model is an attacker obtaining control of the certificate, and now you want to revoke it with DANE. It was previously a valid certificate issued by a CA (and not additive DANE).

No. The threat model is a hostile certificate issued by a government-controlled or a compromised CA. The attacker doesn't have access to my system. This is the main problem with the PKIs, any CA can issue a certificate for any domain.

DANE would require the attacker to not only compromise one CA somewhere, but to compromise my particular top-level domain registrar and my DNS provider.

So basically, you have the matrix:

1. A legacy CA certificate without stapled DANE. The browser will have to do a DNSSEC-secured query to verify that there is no DANE record for this domain name. A browser can cache the outcome ("no DANE record, verified via DNSSEC") for a reasonable time.

2. A CA certificate with "must staple" bit set and a stapled DNSSEC chain. The browser verifies them both, and everything works with zero overhead.

3. A CA certificate without "must staple", and an existing DANE record (that the adversary wasn't able to tamper with). This immediately means an attack.

4. A DANE record without a CA certificate, verified via a stapled DNSSEC chain. This is the optimal outcome.

RFC 9498: The GNU Name System

immibis — Mon, 27 Nov 2023 14:08:34 +0000

> Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."

Every networking technology only sometimes works, because every network packet goes through several adversaries. If this was the logic, browsers should not use HTTP. Or TCP. Or UDP. Or DNS.

RFC 9498: The GNU Name System

immibis — Mon, 27 Nov 2023 14:04:16 +0000

To be fair, it's delegated /etc/hosts. Instead of keeping my own list of names I can decide whose list I trust.

RFC 9498: The GNU Name System

roffey — Mon, 27 Nov 2023 03:38:54 +0000

> Wait, this is literally just /etc/hosts! We already went through this once!

It's not quite /etc/hosts which can only map local names to IPs. For example, it has nicknames and petnames.

> [1] This appears to be GNU's signature move recently

GNUnet was started by Christian Grothoff in 2001 and GNU Name System circa 2013 so it's hardly recent. The RFC is a recent move, just like the RFC for .onion.

Also GNU is a pretty loose collective, GNUnet really only just sits under that large umbrella but it is hardly a coordinated GNU effort.

RFC 9498: The GNU Name System

Wol — Sun, 26 Nov 2023 20:42:49 +0000

> > and there will be some networks that block DNS requests for anything that isn't an "A" or a "CNAME" record.

> Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."

Problem is, browsers are based on what is meant to be a universal platform that works "everywhere".

If the underlying Internet is not a real Internet, then browsers are going to "only sometimes work", and there's nothing the browser developers can do about that. Unfortunately, there are a lot of internet protocols that don't work (ping for example?), because the hardware is intentionally crippled, and there's not a lot software developers can do about it.

Cheers,
Wol

RFC 9498: The GNU Name System

NYKevin — Sun, 26 Nov 2023 18:59:44 +0000

> OSCP must-staple

(Of course, I meant OCSP must-staple.)

RFC 9498: The GNU Name System

NYKevin — Sun, 26 Nov 2023 18:58:38 +0000

> and there will be some networks that block DNS requests for anything that isn't an "A" or a "CNAME" record.

Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."

> Still, adding an X.509 field to signify that the certificate MUST be accompanied by a stapled DNSSEC reply can be an easy incremental improvement.

Presumably, this is restrictive DANE. Your threat model is an attacker obtaining control of the certificate, and now you want to revoke it with DANE. It was previously a valid certificate issued by a CA (and not additive DANE).

(Must-staple provides little or no benefit for additive DANE, because if no DANE response is stapled, then additive DANE probably can't work reliably anyway.)

The obvious objection to this is that OSCP must-staple provides exactly the same benefit, but is actually a real formal specification already. I'm not aware of a spec for DANE must-staple. Unfortunately, nobody implements that one either, but it's a significantly lower technical barrier because the spec already exists, as does most of the necessary tooling.

RFC 9498: The GNU Name System

Cyberax — Sat, 25 Nov 2023 07:18:20 +0000

> This is incomplete. There's a third piece, which is the recursive resolvers. Many of them don't actually validate/return DNSSEC results

You don't need them to. Just ask them to give you RRSIG, DSKEY, and NSKEY records, and do the validation yourself. The recursive resolver will simply act as a dumb cache in this case.

The browsers don't (yet?) want to do that, and there will be some networks that block DNS requests for anything that isn't an "A" or a "CNAME" record.

> Unfortunately, the DANE people wanted to prohibit fallback to CA-signed certificates, or at least implement TOFU-based pinning, similar to HPKP.

Not quite. The problem is that with concurrent deployment of DANE and CAs, there's still a possibility of the attacker simply stripping off the DANE information from the TLS request, leaving only the CA-issued certificate. The working recommended key pinning to fix this (yeah, a great idea).

Still, adding an X.509 field to signify that the certificate MUST be accompanied by a stapled DNSSEC reply can be an easy incremental improvement.

RFC 9498: The GNU Name System

PengZheng — Sat, 25 Nov 2023 04:27:04 +0000

> It follows from the above that GNS does not support names that are simultaneously global, secure, and memorable. Instead, names are either global and not memorable or not globally unique and memorable.

I have a simple question to ask:
When there are multiple websites claiming to be Google, how do users know which is the real one?

RFC 9498: The GNU Name System

NYKevin — Sat, 25 Nov 2023 04:12:24 +0000

> DNSSEC is deployed for all the major TLDs, so you can use it anywhere for these domains. It's not an issue.
>
> The main issue is the end-user support. For some reason, operating systems and browsers resist supporting DNSSEC. It _needs_ to be done on the client side to make a difference.

This is incomplete. There's a third piece, which is the recursive resolvers. Many of them don't actually validate/return DNSSEC results. Furthermore, as of 2015, the Chrome developers were seeing failure to retrieve a simple TXT record on a small but significant percentage of clients,[1] and if that doesn't reliably work, then DANE has no hope of working (DANE records are larger and more recently-specified than TXT records).

In short: You can only have DANE if you have good DNS resolution, and a small but significant portion of clients do not have good DNS.

Chrome could fix this by, for example, unconditionally sending DoH requests to Google or Cloudflare's public DNS servers (which do validate and return DNSSEC, to my understanding) and validating DANE that way, but I imagine that people would freak out if they did that.

Interestingly, there was also talk of putting DANE-signed objects into the TLS handshake and bypassing DNS altogether. Then you really would be able to get away with not having DNSSEC. Unfortunately, the DANE people wanted to prohibit fallback to CA-signed certificates, or at least implement TOFU-based pinning, similar to HPKP. The browser people responded that they had just finished putting out the fire that was HPKP (it turns out that irrevocable pinning is a great way to shoot yourself in the foot), and they were not eager to start a second one, so the whole thing fizzled out.[2]

[1]: https://www.imperialviolet.org/2015/01/17/notdane.html
[2]: https://blog.apnic.net/2019/07/05/whither-dane/

RFC 9498: The GNU Name System

Cyberax — Sat, 25 Nov 2023 03:59:03 +0000

> * All forms of DANE require DNSSEC, whose deployment is (to put it charitably) less than complete, at least in some regions.

DNSSEC is deployed for all the major TLDs, so you can use it anywhere for these domains. It's not an issue.

The main issue is the end-user support. For some reason, operating systems and browsers resist supporting DNSSEC. It _needs_ to be done on the client side to make a difference.

But once you have DNSSEC, you can easily use DANE alongside the normal CA. A nation-state can still MITM you by forging a certificate, but they won't be able to fool the clients that do DNSSEC resolution themselves. So it's strictly better security.

> Why would anyone even bother configuring one in the first place?

Mostly because nobody validates DANE records as of now.

RFC 9498: The GNU Name System

NYKevin — Sat, 25 Nov 2023 00:04:19 +0000

The basic problems with DANE, to my understanding, are roughly as follows:

* All forms of DANE require DNSSEC, whose deployment is (to put it charitably) less than complete, at least in some regions. This is getting better over time, but it certainly has not encouraged browsers to rush into supporting DANE.
* Restrictive DANE, in particular, requires the browser to hard-fail any connection where DNSSEC is not available, because a MitM attacker can probably induce that failure mode (unless using something like DoH for end-to-end encrypted DNS requests and responses, but most ISPs do not deploy DNS in that fashion).
* Restrictive DANE does not offer enough of a value-add over Certificate Transparency, at least from the browsers' perspective (i.e. they know they can reliably find and distrust CAs who issue rogue certs for large, well-known domains, and it is not too difficult for a small, less well-known domain to find and report such a rogue cert, so the browsers, somewhat credibly, believe that CAs will not be willing to attempt issuing such rogue certs at all).
* Additive DANE is, in practice, mostly or entirely redundant to Let's Encrypt. Also, any clients who don't have DNSSEC and/or DANE support won't be able to view your website, so in practice you would need a regular non-DANE certificate anyway (at least until those technologies are fully supported by everyone everywhere). At that point, the DANE certificate is dead weight. Why would anyone even bother configuring one in the first place?

RFC 9498: The GNU Name System

pizza — Fri, 24 Nov 2023 14:12:47 +0000

> IIUC the server would need the private key corresponding to the link’s public key?

No, because once the IP is resolved, GNS (and DNS's) role in the connection has ended; the rest is in the application's hands. If the correct IP has been taken over (or is being MITM'd) by a hostile actor, data sent back or forth will be compromised. Even if TLS is used as another protection layer, if the attacker has the resources to hijack IP addresses, they probably have access to a dodgy CA that allows them to also forge TLS certificates (various national TLAs have these resources, and it's also how well-documented national firewalls tend to work too)

(But wait, you might say, one can serve HTTPS/TLS keys via GNS! But you can do this with DNS too, via the DANE proposal. Which I really wish browsers would support so we could ditch the dumpster fire that is the 3rd-party CA infrastructure)

RFC 9498: The GNU Name System

ms-tg — Fri, 24 Nov 2023 10:20:12 +0000

IIUC the server would need the private key corresponding to the link’s public key?

RFC 9498: The GNU Name System

jamesh — Fri, 24 Nov 2023 08:38:55 +0000

If you're using GNS to resolve names to IP addresses, wouldn't IP address hijack be just as big an issue as it is with DNS?

RFC 9498: The GNU Name System

pizza — Fri, 24 Nov 2023 00:10:38 +0000

> About exactly the same way you do it with DNS, really.

With DNS you'd query the global authoratative root, with records signed by DNSSEC, and connect to an IP that uses a TLS certificate that matches the domain name. But with GNS, you have to already know who to contact before you can ask them to resolve an address.

(If you can get a direct link via a search engine or some sort of 3rd-party directory, guess what, that same mechanism works with bog-standard DNS as well, and GNS has added nothing. Less than nothing, really, as it's made the user experience _worse_)

So, once again, how does GNS solve (or even improve upon) DNS's [in]ability to determine if a given site is "legit"? At best it's no different, but in practice it's going to be much, much worse.

RFC 9498: The GNU Name System

ballombe — Thu, 23 Nov 2023 22:44:45 +0000

> So how does the user know (in advance) what hostname for "linux weekly news" is "legit" and thus should go into their address book?

About exactly the same way you do it with DNS, really.

RFC 9498: The GNU Name System

pizza — Thu, 23 Nov 2023 20:30:51 +0000

> The user manages it using their bookmark and contact tools, as for phone numbers

You forget that for phone numbers, there is an authoritative registry (ie the phone company) that tells you the legal name associated with a given number.

> The only thing readable names provide is a false sense of familiarity that make some hostname looks 'legit',

So how does the user know (in advance) what hostname for "linux weekly news" is "legit" and thus should go into their address book?

> when the DNS system does not at all assure in any way they point to a legit website.

GNS is no better in this respect.

> With the GNS, all unknown hostnames look equally dodgy.

Again, how do you determine which of these "equally dodgy" unknown hostnames is the legitimate "lwn.net"?

I don't doubt that GNS has some niche use cases, but it is in no way a general replacement for DNS. Indeed, given the degree of manual configuration/delegation needed for a GNS resovler to accomplish anything, I'm far from convinced that GNS has anything to offer over doing a similar degree of manual configuration/delegation to an off-the-shelf DNS resolver.

RFC 9498: The GNU Name System

ballombe — Thu, 23 Nov 2023 19:55:58 +0000

The user manages it using their bookmark and contact tools, as for phone numbers.
The only thing readable names provide is a false sense of familiarity that make some hostname looks 'legit',
when the DNS system does not at all assure in any way they point to a legit website.
With the GNS, all unknown hostnames look equally dodgy.

RFC 9498: The GNU Name System

pizza — Thu, 23 Nov 2023 14:17:45 +0000

> Realistically bigcorp.com will be in the user directory.

So.... who sets up and then maintains this "user directory"?

RFC 9498: The GNU Name System

paulj — Thu, 23 Nov 2023 10:51:51 +0000

So basically the same problem as Tor Onion "dark web" has. Tor Onion host names are derived from keys too. It's very easy for people to put up fakes of popular "e-commerce" (cough) sites, and it's almost impossible for users to know which site is the legitimate one. So some users started creating "book mark" sites to link to the genuine sites - except they can't keep up with what is legit and what is a copycat scam either ;).

RFC 9498: The GNU Name System

ballombe — Thu, 23 Nov 2023 10:18:03 +0000

The URL will include the hostname as a number string, and the web browser will look in the directory to display it to the user. Unknown host will still be displayed as numbers, which prevent users to be tricked by lookalike domain names.
Realistically bigcorp.com will be in the user directory.

RFC 9498: The GNU Name System

rrolls — Thu, 23 Nov 2023 08:02:35 +0000

To be fair, this does appear to provide a name system that, once configured locally, ensures the petname you put in always points where you think it does. It's a little more than "just /etc/hosts": if you use /etc/hosts to map example.com to 1.2.3.4, you still need some way of knowing that some hijacker hasn't stolen the IP address 1.2.3.4, just like with DNS you need some way of knowing that some hijacker hasn't stolen example.com. Of course, TLS solves that problem in both cases... but TLS, like DNS, requires some trusted root. It seems to me like GNS basically wants to absorb the "how do you trust the server is who it says it is" function of TLS, which is a nice development.

But it doesn't seem to go much further than that. :\

Something I've been casually mulling over for years, that I've never seen anyone experiment with, but I'd love to see attempted, is a protocol/standard that achieves the following:

1. User configures their brand new device to trust a _single_ public key, for sake of argument, the pubkey of their favorite website.
2. User goes to their favorite website. That public key they trusted allows getting to it, no central TLS/DNS required, in a similar manner to SSH (which doesn't require any central trust root, it just requires TOFU). Actually finding the website can be done by some kind of DHT, like GNS suggests.
3. Each link on the website isn't just a link: it also includes a public key. It's an assertion that the maintainer of the website trusts that the pubkey served with the link is correct for whatever the link points to. Clicking a link doesn't just navigate to it, it also caches the assertion, so that the link target can be served despite that the user didn't explicitly trust that pubkey yet. Instead, the user is trusting their favorite website's maintainer that their assertions are correct; and so on, for links from those websites, etc.
4. Those cached assertions would be maintained locally in some kind of graph "web-of-trust" representation; if any were later discovered to be incorrect (either by the user, or some kind of automatic revocation system), it could be updated accordingly, and invalid assertions stripped out.

If in step 1 we're talking a non-tech-savvy user here, it could be configured by the tech-savvy friend who gets them their new device; or by the computer shop; or whatever. Yes, if you're buying a device from a big name, they'd just configure their own, and people would then want some chain of trust back to that big name, so it'd be similar to the centralisation of DNS/TLS in that respect; but it would be trivial to remove the default root and add another, or have multiple roots; and far more importantly, _anyone_ can take the role of a "CA", simply by serving a good old-fashioned link.

RFC 9498: The GNU Name System

rrolls — Thu, 23 Nov 2023 07:39:15 +0000

I'm so happy to see this was exactly what I guessed it would be :)

RFC 9498: The GNU Name System

Cyberax — Thu, 23 Nov 2023 04:50:08 +0000

"Yeah, go to LWN.net, but be sure to get the one that ends with 283ABF123"

RFC 9498: The GNU Name System

pizza — Thu, 23 Nov 2023 01:09:36 +0000

> Most people never type an URL in an address bar, so this is not a real issue.

So, when folks click on "bigcorp,com" in their google/facebook/whatever search results, how will their computer know what IP address to connect to?

DNS underpins *everything* on the internet. And ironically, that includs GDNS as well, as evidenced by its GNS2DNS redirection records.

RFC 9498: The GNU Name System

rra — Wed, 22 Nov 2023 21:53:23 +0000

He gave a talk proposing exactly that at the Stanford Computer Science department around that time frame. I was there in person. I'm fairly sure there were various mailing list posts about it as well. The justification was that you could use address books and bookmarks and cut and paste.

Like many Dan Bernstein ideas, it is possible, even likely, that it involved some combination of reduction to first principles and tongue-in-cheek, but he was definitely pushing it at the time. This was back before he gave up / got distracted from Internet protocols and focused mostly on encryption algorithms.

RFC 9498: The GNU Name System

ballombe — Wed, 22 Nov 2023 21:38:15 +0000

Most people never type an URL in an address bar, so this is not a real issue.

RFC 9498: The GNU Name System

Cyberax — Wed, 22 Nov 2023 21:37:42 +0000

DJB has been (essentially) pushing for the NS records to be used to carry the public keys for DNS query encryption. I'm not aware of him trying to push a flat namespace of public keys instead of names.

RFC 9498: The GNU Name System

Cyberax — Wed, 22 Nov 2023 21:25:59 +0000

I'm going to just leave it here: https://www.youtube.com/watch?v=HWc3WY3fuZU

RFC 9498: The GNU Name System

rra — Wed, 22 Nov 2023 21:05:38 +0000

Dan Bernstein has been pushing this idea since at least 2003 without much success. (I notice that he's mentioned in the credits; I thought this designed looked familiar.) I'm dubious that this round of the idea will be any more successful. People want the globally-unique human-meaningful name, a lot.

I think there is a narrow use case where this is a useful solution (you want a unique name for some endpoint that may change IP addresses regularly and you don't care about it being human-readable), but it's not the DNS use case.

RFC 9498: The GNU Name System

pizza — Wed, 22 Nov 2023 14:41:33 +0000

> Wait, this is literally just /etc/hosts! We already went through this once!

Yep. And if you want to create your own internal/private domains you can trivially do that with existing DNS servers and resolvers. Heck, everyone with a consumer-grade wifi router is already using such a setup [1], whether they realize it or not.

[1] via dnsmasq

RFC 9498: The GNU Name System

atnot — Wed, 22 Nov 2023 14:18:13 +0000

Wait, this is literally just /etc/hosts! We already went through this once!

We had people manually entering network adresses, then writing aliases, then copying around host files, then querying local trusted servers, then querying our current, globally distributed domain name system.

We had lists of useful dns names printed on paper, we had curated directories and web rings, we had ranking search engines that would correct your parents typos, we had link aggregators and now we have app stores and capital P Platforms where nobody that uses them could even tell you what their DNS name is.

It doesn't sound like the creators of GNS have any answers for the forces that caused these things to happen, apart from a desire to set the clock back half a century[1]. Instead they seem to have only added bad ideas created since.

From things like cryptocurrency and even PGP we have learned that few end users are capable of managing sensitive long lived key material and even fewer enjoy that sort of responsibility and just flock to unaccountable centralized services instead. We have learned that at a societal scale, flexibility and humans in the loop that can resolve conflicts and reverse mistakes are far more valuable than mathematical rigidity. It is actually quite good that if someone breaks into a server or registrar, the domain is not compromised forever.

We already have things like TOR hidden services or to a lesser extent IPFS, that deliberately accept these drawbacks for their narrow use cases. But GNS doesn't seem to have any of that.

[1] This appears to be GNU's signature move recently

RFC 9498: The GNU Name System

dvrabel — Wed, 22 Nov 2023 13:07:59 +0000

"Thanking you for calling Foo Corp Customer Services, Our lines are all busy right now. For help online go to support dot zero zero zero, golf, tango, bravo, five, seven, zulu, ...." (1 minute later) "Press 9 to repeat that address."

I don't think a long random string of characters is really equivalent to a 11-digit phone number.

RFC 9498: The GNU Name System

farnz — Wed, 22 Nov 2023 10:05:03 +0000

The only reason that we have a single DNS, and not multiple, is that there's value from us all agreeing that when I talk about "LWN.net", I mean this site, and not a different host (which is exploited by - for example - TLS's use of X.509 certificates that tie the identity to DNS name). In theory, though, my DNS servers could have their own private TLD, and rewrite lwn.net.iana to lwn.net before asking the IANA roots to resolve it.