Alternative DNS Roots(scholz.ruhr)
scholz.ruhr
Alternative DNS Roots
https://scholz.ruhr/post/alternative-dns-root/
73 comments
DNS is the literally the only compelling use case for blockchain that I have ever been able to come up with (besides paying for contraband). A distributed database that no single entity owns is a perfect match for name resolution. Kind of amusing to me that blockchain DNS hasn't gotten off the ground. What hope do the less compelling blockchains have?
How would you actually accomplish a DNS blockchain? To run DNS-style Internet naming on a blockchain, you have to take control of the DNS roots. The DNS roots are community property. Unless ICANN came up with some process for starting a blockchain-based DNS, any new blockchain-based DNS would essentially be seizing community property by fiat. Nobody is going to let any private organization do that.
Nope, sane projects would have 1 TLD they have names under and clients opt-in to resolution. Handshake is awful because it pretends it has the right to control the root and adds TLDs in such a way that there's no way to tell if a given domain needs to be resolved with handshake. Also it allows for numerical names which could collide with IPs. Don't use Handshake. ENS is also bad (no SPV, you usually end up relying on Infura), "Unstoppable" domains has all the problems of ENS, plus too many TLDs, and names can only be registered through the official servers. NameCoin might be ok, haven't looked into it too much. EmerCoin promises too much which makes me suspicious. (Like blockchain VoIP? What?) If I missed any, please let me know.
Sounds pretty much like the GNU Name System. With what they call a hyper hyper local root, you as a client define your own TLDs in addition to the root your system has configured (the system is intended to replace the existing ICANN root in a backwards-compatible manner).
Delegation happens via public key and records are resolved through a DHT. The idea is you could add your friend/org's key to your root, and from there you could resolve recursively using your friend/org's zone.
Pretty neat stuff, at least on paper.
Delegation happens via public key and records are resolved through a DHT. The idea is you could add your friend/org's key to your root, and from there you could resolve recursively using your friend/org's zone.
Pretty neat stuff, at least on paper.
IMO, GNS would benefit from a blockchain to store the root zone. Currently, It is managed by a non-profit. You can add your own TLD but good luck enabling everyone to resolve it without GNUnet e.V's say-so.
The problem is making a blockchain that's private enough.
I would say GNS proposes an interesting tradeoff, at least one that's not been attempted/proposed by other projects. They intend their root zone to be transferred to ICANN for ownership and for the protocol to be backwards-compatible with DNS, so that moving to GNS wouldn't require major updates from all providers/vendors (unlike IPv6).
Also, the hyper hyper local root and public-key delegation balance the powers of the centralized root. Hypothetically, adding a new "TLD" (for your client) would be very easy so we would probably see more old-style "indexes" sharing zones you could subscribe to, also in a peer-to-peer manner so that if i add my friend anita's zone to my root, i could then recursively resolve through her published index (in her zone), like blog.anita or barbara.anita (a hypothetical friend of anita's).
It's also worth mentioning that this would significantly change the Certificate Authority problem by having a secure network to distribute the keys via DANE entries. It would still be a problem though that anita could suddenly point barbara in her zone to her own machine and serve her own content/certificate. But i guess that's what Web of Trust (or rather Fog of Trust with zero-knowledge proofs) is for? :)
Also, the hyper hyper local root and public-key delegation balance the powers of the centralized root. Hypothetically, adding a new "TLD" (for your client) would be very easy so we would probably see more old-style "indexes" sharing zones you could subscribe to, also in a peer-to-peer manner so that if i add my friend anita's zone to my root, i could then recursively resolve through her published index (in her zone), like blog.anita or barbara.anita (a hypothetical friend of anita's).
It's also worth mentioning that this would significantly change the Certificate Authority problem by having a secure network to distribute the keys via DANE entries. It would still be a problem though that anita could suddenly point barbara in her zone to her own machine and serve her own content/certificate. But i guess that's what Web of Trust (or rather Fog of Trust with zero-knowledge proofs) is for? :)
ENS is not necessarily relying on Infura, I could imagine resolution being run by your ISP like it is common with DNS.
Because ISPs do such a great job with DNS now...
I don't see how a root would be involved. As I understand it, a "DNS blockchain" is basically "/etc/hosts, but as a distributed ledger".
You create a new DNS root, like in TFA.
The "root" we're talking about here is the namespace. Creating and promulgating a new one is a seizure of that namespace. This isn't a moral argument; it's an observation about plausible adoption. To wit: nobody is going to adopt a new root namespace that's monetized for its creators.
Which leaves me the question of how blockchain DNS could ever come to pass. What's in it for the project that pulls it off? The answer to that question is likely the reason it won't come to pass.
Which leaves me the question of how blockchain DNS could ever come to pass. What's in it for the project that pulls it off? The answer to that question is likely the reason it won't come to pass.
The project can be non-profit, like ENS was in the beginning, automatically burning the proceeds of the auctions.
I mean, anything that happens here would have to be a non-profit with really strong commitments not to enrich the founders, or it's DOA. But that's a necessary and not sufficient condition; you can imagine all sorts of non-profit attempts to effectively reclaim the roots that would fail for reasons other than money; for instance, such a project would also need to have governance matching the expectations of the rest of the Internet, which is tricky to do.
From what I have seen the existing/proposed implementations suffer from the same problems that ICANN DNS has had, namely, artificial scarcity, vanity names, "gold rush/land grab" and commercialisation schemes.
The ideal system, IMO, would be one where anyone can get a name, no one can "hoard" names, and all names are of equal value. As such, the profit motive, and thereby the impetus for corruption, is removed. I have created such DNS at home, I run an "alternate root" on the loopback. It's ideal for me.
The ideal system, IMO, would be one where anyone can get a name, no one can "hoard" names, and all names are of equal value. As such, the profit motive, and thereby the impetus for corruption, is removed. I have created such DNS at home, I run an "alternate root" on the loopback. It's ideal for me.
How would such a thing work from a standpoint of human interaction?
The "vanity names" are the primary value of DNS to the majority of its users, and the desirable ones will always inherently be scarce.
Obviously something similar to a .onion address would fit your criteria, but no one is ever going to seriously consider anything like that as a realistic alternative to ICANN DNS.
The "vanity names" are the primary value of DNS to the majority of its users, and the desirable ones will always inherently be scarce.
Obviously something similar to a .onion address would fit your criteria, but no one is ever going to seriously consider anything like that as a realistic alternative to ICANN DNS.
> The ideal system, IMO, would be one where anyone can get a name, no one can "hoard" names, and all names are of equal value.
I’m immediately reminded of Tor .onion names, though those aren’t exactly user-friendly…
I’m immediately reminded of Tor .onion names, though those aren’t exactly user-friendly…
The alternative would be for people to always rely on a search engine to actually get the sites they want and never really enter URLs by hand. We are not that far from that, to be honest. There are many people who will search for the site name and click the first link rather than type in the url. Sometimes their search comes up as a suggestion before they press enter, but it's still the same idea of not relying on the actual DNS name.
The idea I implemented as an experiment at home is DNS names that contain encoded information. For example, the TLD contains a number that represents a certain trademark class of good/services. Subcategories are encoded in domain, subdomain1, subdomain2, etc. becoming more specific as one reads from right to left. Thus one can perform searches only on the domainname (and optionally the URL). This is faster and easier than searching the contents of web pages. Another portion of the domain name is a public key. For some types of content, this works well. It is like searching a directory.
That's more or less how yahoo! directory worked (obviously not at the DNS level), however, google showed that crawling the contents and indexing everything, while certainly a lot more complex, it is a lot easier to use. So, while that idea is probably better and more discoverable than the current DNS system, it seems more likely to me that the replacement for DNS will be free text search.
At some point, browsers will finally manage to get rid of the address bar and have everything working fully operated via suggestions/search. Then, DNS will become sort of irrelevant for the web.
At some point, browsers will finally manage to get rid of the address bar and have everything working fully operated via suggestions/search. Then, DNS will become sort of irrelevant for the web.
Sounds plausible however I am not much of browser fan, while I really do like the speed and size of DNS software, so I will always be experimenting with different approaches. The world of the web browser is dominated by advertising and surveillance. Unless that changes, I care little about what the web browser may or may not do in the future. I am more interested in relatively small DNS software.
Neither are telephone numbers … being exactly a user-friendly thingie but there we go.
Phone numbers are the IP addresses. Your contact list (or the yellow/white pages in days long past) is the DNS server for them.
Vastly more user-friendly than .onion names, I'd say :P
Only by the virtue of being a less combinatorial options of the few, 10 to 15 digit telephone number that is.
That's why people have phone books and contact lists.
Onions are globally unique and secure. It would be interesting to add a "social" human-meaningful layer pointing to those unique/secure names, much like the GNS project tries to do.
As per usual, it depends very much on what you consider a blockchain. Is Certificate Transparency a blockchain? It's a Merkle tree, without any tokens involved.
What would something like AlterNIC have looked like if it was backed by a blockchain? Would it have had easier acceptance, or more reliability?
What would something like AlterNIC have looked like if it was backed by a blockchain? Would it have had easier acceptance, or more reliability?
No, AlterNIC would have failed regardless of the underlying technology. Its founder became a pariah. It's similar in a lot of ways to Handshake; just imagine that Handshake gets tired of nobody but Opera resolving its names, and then it hacks ICANN, and you've got pretty much a replay of that situation.
It's worth comparing 1997 to 2022 to see why attempts to seize the Internet roots are unlikely to go anywhere. It's similar in a bunch of ways to the WebPKI. For all its faults, AlterNIC had a better case against Network Solutions than anyone has against ICANN: Internet governance at the time prohibited new TLDs, and registrars were rapacious. But over the next 10 years, that mostly changed, just like the WebPKI has been drastically cleaned up after abuses in the 2000s.
People continually propose replacements for the WebPKI today that seem premised on a CA system that works like it did in 2005. But we don't have the 2005 WebPKI; we have 2022's.
(I was doing DNS security work at the time Kashpureff cache poisoned internic.net, and it was a pretty formative experience for me, if people wonder why I'm so shocked that anyone would take Handshake seriously).
It's worth comparing 1997 to 2022 to see why attempts to seize the Internet roots are unlikely to go anywhere. It's similar in a bunch of ways to the WebPKI. For all its faults, AlterNIC had a better case against Network Solutions than anyone has against ICANN: Internet governance at the time prohibited new TLDs, and registrars were rapacious. But over the next 10 years, that mostly changed, just like the WebPKI has been drastically cleaned up after abuses in the 2000s.
People continually propose replacements for the WebPKI today that seem premised on a CA system that works like it did in 2005. But we don't have the 2005 WebPKI; we have 2022's.
(I was doing DNS security work at the time Kashpureff cache poisoned internic.net, and it was a pretty formative experience for me, if people wonder why I'm so shocked that anyone would take Handshake seriously).
Comparing Eugene's exploit to a decentralized root owned by the commons that complements ICANN's system is confusing to me. I can understand how his exploit could be a formative experience for you, what I can't understand is how that experience relates to Handshake.
What you're saying is like, "imagine if a security researcher decided he was tired of getting paid much less than he deserves and decides to hack a bank," and then using this imagined experience as a "logical" reason to hold disdain for something.
You're welcome to your opinion, but please stop trying to paint a false picture about Handshake specifically unless you're using actual facts that are real life and not imagined.
What you're saying is like, "imagine if a security researcher decided he was tired of getting paid much less than he deserves and decides to hack a bank," and then using this imagined experience as a "logical" reason to hold disdain for something.
You're welcome to your opinion, but please stop trying to paint a false picture about Handshake specifically unless you're using actual facts that are real life and not imagined.
There is Handshake [1] which is getting significant [2] adoption [3].
[1] https://handshake.org/
[2] https://twitter.com/opera/status/1476841607005622273?s=20
[3] https://www.namecheap.com/about/press-releases/21-09-22/name...
[1] https://handshake.org/
[2] https://twitter.com/opera/status/1476841607005622273?s=20
[3] https://www.namecheap.com/about/press-releases/21-09-22/name...
Handshake has no meaningful adoption. It's a pre-mined cryptotoken, traded on exchanges; essentially, the Handshake founders decided to sell the Brooklyn Bridge, which is something that blockchains make feasible. No mainstream browser will ever support Handshake.
More's the pity! If the Handshake DNS root heist works, it'd open up new business models for all of us. I had been looking forward to minting ARPCoin and charging everyone to join their WiFi networks.
More's the pity! If the Handshake DNS root heist works, it'd open up new business models for all of us. I had been looking forward to minting ARPCoin and charging everyone to join their WiFi networks.
rasengan(1)
You can't really count Opera as "significant".
Handshake domains are only accessible by a tiny percent of people, make stuff like HTTPS very difficult[1], and no matter how devices eventually use Handshake, you'll always need to have a domain on a normal TLD because there will always be devices (like TVs and old phones) that will not support it.
And what benefit do you get anyways? A custom TLD? There's already so many new TLDs but most domains are on gTLDs or ccTLDs because thats what people recognize. Even Google and Apple barely use theirs. Ownership? Not really. Handshake only manages TLDs. Buying a subdomain (like you can on Namecheap) doesn't happen on the blockchain, the owner of the TLD can take it away anytime. Say what you want to say about ICANN, but they do have rules (such as contingency plans) that new TLD owners have to follow. In what world is buying a handshake subdomain from an unknown person beholden to nobody better in any way?
[1] https://www.namecheap.com/support/knowledgebase/article.aspx...
Handshake domains are only accessible by a tiny percent of people, make stuff like HTTPS very difficult[1], and no matter how devices eventually use Handshake, you'll always need to have a domain on a normal TLD because there will always be devices (like TVs and old phones) that will not support it.
And what benefit do you get anyways? A custom TLD? There's already so many new TLDs but most domains are on gTLDs or ccTLDs because thats what people recognize. Even Google and Apple barely use theirs. Ownership? Not really. Handshake only manages TLDs. Buying a subdomain (like you can on Namecheap) doesn't happen on the blockchain, the owner of the TLD can take it away anytime. Say what you want to say about ICANN, but they do have rules (such as contingency plans) that new TLD owners have to follow. In what world is buying a handshake subdomain from an unknown person beholden to nobody better in any way?
[1] https://www.namecheap.com/support/knowledgebase/article.aspx...
> You can't really count Opera as "significant".
380m+ users seems significant to me.
> Handshake domains are only accessible by a tiny percent of people
Actually, NextDNS which is a Firefox resolver also supports Handshake, so I imagine it's not a tiny percent of people.
> make stuff like HTTPS very difficult
Additionally, HTTPS is completed by Handshake since it removes the need for a "trusted certificate authority" which, as many articles have mentioned as of late, is not so trusted [1][2].
> you'll always need to have a domain on a normal TLD because there will always be devices (like TVs and old phones) that will not support it.
TVs and old phones can support handshake since it's just regular DNS protocol.
> And what benefit do you get anyways?
You will cryptographically own your own name.
> A custom TLD?
A name all-inclusive. Hard stop.
> There's already so many new TLDs but most domains are on gTLDs or ccTLDs because thats what people recognize.
I've been around for a long time -- the internet has evolved and continues to evolve. People change quickly.
> Ownership? Not really. Handshake only manages TLDs.
Cryptographically owning things is likely a more constant ownership than a 'binding ownership' by a legal contract in some jurisdiction.
Some of the statements you made about subdomains may or may not be true, but it's not any worse than today and likely better since there will be more options of TLD owners to choose from should one choose to purchase a TLD.
[1] https://github.com/imperviousinc/beacon-ios
[2] https://blog.mozilla.org/security/2021/12/09/improved-qualit...
380m+ users seems significant to me.
> Handshake domains are only accessible by a tiny percent of people
Actually, NextDNS which is a Firefox resolver also supports Handshake, so I imagine it's not a tiny percent of people.
> make stuff like HTTPS very difficult
Additionally, HTTPS is completed by Handshake since it removes the need for a "trusted certificate authority" which, as many articles have mentioned as of late, is not so trusted [1][2].
> you'll always need to have a domain on a normal TLD because there will always be devices (like TVs and old phones) that will not support it.
TVs and old phones can support handshake since it's just regular DNS protocol.
> And what benefit do you get anyways?
You will cryptographically own your own name.
> A custom TLD?
A name all-inclusive. Hard stop.
> There's already so many new TLDs but most domains are on gTLDs or ccTLDs because thats what people recognize.
I've been around for a long time -- the internet has evolved and continues to evolve. People change quickly.
> Ownership? Not really. Handshake only manages TLDs.
Cryptographically owning things is likely a more constant ownership than a 'binding ownership' by a legal contract in some jurisdiction.
Some of the statements you made about subdomains may or may not be true, but it's not any worse than today and likely better since there will be more options of TLD owners to choose from should one choose to purchase a TLD.
[1] https://github.com/imperviousinc/beacon-ios
[2] https://blog.mozilla.org/security/2021/12/09/improved-qualit...
I literally own my lastname as a Handshake TLD. I got it way back in September 2020, when they were still slowly releasing them. I love the idea of using first.lastname. It's great branding. However, my personal benchmark is can I hand a random person a business card and expect them to be able to visit my site. The answer to that right now is very clearly no and so it sits unused.
Adoption by default is a huge deal and you can't ignore it by saying that something "can" use it if you configure your router properly or this and that. The vast majority of people will never change it. Re. Firefox, I just tried switching it to NextDNS, but it seems like the default NextDNS resolver does not resolve Handshake domains.
Putting aside all the issues with DANE as a replacement to HTTPS, no browser supports it. This is why I don't use my handshake TLD for my personal/internal sites either.
Look, actual Handshake adoption would benefit me quite a bit, since I own a great TLD. I will keep an eye on adoption, but its very clearly a long road, and the project itself has a number of issues besides just adoption. It's cool, but you have to be realistic.
Adoption by default is a huge deal and you can't ignore it by saying that something "can" use it if you configure your router properly or this and that. The vast majority of people will never change it. Re. Firefox, I just tried switching it to NextDNS, but it seems like the default NextDNS resolver does not resolve Handshake domains.
Putting aside all the issues with DANE as a replacement to HTTPS, no browser supports it. This is why I don't use my handshake TLD for my personal/internal sites either.
Look, actual Handshake adoption would benefit me quite a bit, since I own a great TLD. I will keep an eye on adoption, but its very clearly a long road, and the project itself has a number of issues besides just adoption. It's cool, but you have to be realistic.
> but it seems like the default NextDNS resolver does not resolve Handshake domains.
https://help.nextdns.io/t/83hmv0v/what-is-handshake
> Putting aside all the issues with DANE as a replacement to HTTPS
The issues with DANE no longer exist when the blockchain serves as the root of trust, thus completing a chain of trust in a way that a third party certificate authority is unneeded. It's DANE without the potential for backdoor.
> Look, actual Handshake adoption would benefit me quite a bit, since I own a great TLD. I will keep an eye on adoption, but its very clearly a long road, and the project itself has a number of issues besides just adoption. It's cool, but you have to be realistic.
I agree there is a lot to do still, but the adoption Handshake has is more than significant in the context of alternate roots given it's adopted by so many DNS registrars and natively integrated into large userbase services and software. But no, it's not in Chrome... yet.
https://help.nextdns.io/t/83hmv0v/what-is-handshake
> Putting aside all the issues with DANE as a replacement to HTTPS
The issues with DANE no longer exist when the blockchain serves as the root of trust, thus completing a chain of trust in a way that a third party certificate authority is unneeded. It's DANE without the potential for backdoor.
> Look, actual Handshake adoption would benefit me quite a bit, since I own a great TLD. I will keep an eye on adoption, but its very clearly a long road, and the project itself has a number of issues besides just adoption. It's cool, but you have to be realistic.
I agree there is a lot to do still, but the adoption Handshake has is more than significant in the context of alternate roots given it's adopted by so many DNS registrars and natively integrated into large userbase services and software. But no, it's not in Chrome... yet.
Who's the most credible security engineer you can find that publicly believes that Handshake will replace X.509 CAs in the WebPKI?
How is radically improved transparency in the WebPKI --- what you linked to --- evidence that Handshake is more trustworthy than the WebPKI?
How is radically improved transparency in the WebPKI --- what you linked to --- evidence that Handshake is more trustworthy than the WebPKI?
handshake.org
DNS over http will eventually destroy DNS as we know it. Thanks Goog n co!
DNS at the moment over 53/UDP is manageable and malleable. DNS over http is not and is up to your browser and hence a vendor.
Life on the helpdesk will become rather more nasty and worse than it is now and we probably won't get tools to diagnose what is going on inside the browser, and so life for IT will be increasingly crap.
I suggest we don't let the FAANGS run the world or the browser.
DNS at the moment over 53/UDP is manageable and malleable. DNS over http is not and is up to your browser and hence a vendor.
Life on the helpdesk will become rather more nasty and worse than it is now and we probably won't get tools to diagnose what is going on inside the browser, and so life for IT will be increasingly crap.
I suggest we don't let the FAANGS run the world or the browser.
DoH does not depend on a browser! Try this out with cURL
[0] https://github.com/DNSCrypt/dnscrypt-proxy
curl --http2 -H 'accept: application/dns-json' "https://1.1.1.1/dns-query?name=cloudflare.com" --next --http2 -H 'accept: application/dns-json' "https://1.1.1.1/dns-query?name=example.com"
[0] https://github.com/DNSCrypt/dnscrypt-proxy
I personally consider curl to be a CLI web browser.
Is this satire? DNS is not malleable when every middlebox fucks with your queries. The protocol rusted in place a long time ago.
there are still environments (countries, orgs, isps) were dns fuckery is kept low and the overhead of dot/doh is just wasted energy/time.
not to say it is bad to have secure alternatives, but i think the internet will loose a lot of resiliancy and efficiency in the switch.
not to say it is bad to have secure alternatives, but i think the internet will loose a lot of resiliancy and efficiency in the switch.
Exactly. DoH seems a fix to work around US ISP monopolies vs something actually desirable. Normal DNS has plenty of opportunities to work around bad providers and keep going.
DNS over port 53 (udp/tcp actually) is no different from the manageability perspective, browsers could just have easily decided to skip the OS resolver with a TCP socket and just because it's HTTPS doesn't mean you cant still do resolution at the system level with it.
> DNS at the moment over 53/UDP is manageable and malleable.
As for that malleable part... You always trust the networks you're on? Because my ISP, in the US, will inject JS into an insecure page load when I'm at 80% of my monthly data cap - I can only assume they're sniffing anything and everything in the clear. It's 2022, we shouldn't consider insecure transports viable. Zero trust, cliche or otherwise.
As for that malleable part... You always trust the networks you're on? Because my ISP, in the US, will inject JS into an insecure page load when I'm at 80% of my monthly data cap - I can only assume they're sniffing anything and everything in the clear. It's 2022, we shouldn't consider insecure transports viable. Zero trust, cliche or otherwise.
people have been trying to make various competing alternate DNS roots a "thing" for about 22 years now, and I would wager good money that less than 0.01% of the worldwide installed operating system base for client devices are configured to use them.
I'd guess maybe 25 years. Pretty sure "alternative" DNS roots were already a thing I had scoffed at by the time I moved out of my first student house in 1998. That's the first place I lived which had Always On Internet Access, 56kbps 24/7 shared between six people over 10base2 Ethernet.
Next blogpost: Alternative certificate authority
FYI: There is CAcert.org[1][2], which attempted to establish a community run authority (long before let's encrypt was a thing) and IIRC Mozilla was at least discussing including their root cert.
I remember some years back at Chaos Congress in Hamburg, a friend of mine who was very enthusiastic about CAcert physically met with a few CAcert people to show them his passport and get his certificate signed.
[1] http://www.cacert.org/
[2] https://en.wikipedia.org/wiki/CAcert.org
I remember some years back at Chaos Congress in Hamburg, a friend of mine who was very enthusiastic about CAcert physically met with a few CAcert people to show them his passport and get his certificate signed.
[1] http://www.cacert.org/
[2] https://en.wikipedia.org/wiki/CAcert.org
imo if cacert had bee included in any major browser, it would have dumpstered the ca-industry in a week. the verification process with passports and physical meetings meant it had better security and crowdsourcing made it effectively free of charge; billions of revenue just gone.
You'd have needed at least Mozilla and Microsoft to be on-board. The failure mode for a CA is that someone cannot use your site and that's not something you can ignore for serious usage — it took Let's Encrypt years and backing by influential organizations to get established. I like CA Cert, got verified with my passport at Usenix, etc. but still ended up not using it anywhere except some personal servers because life is way too short to walk people through installing a CA, especially with the knowledge that you're training them to be susceptible to attacks.
That post is in the works for months now, I have a huge list of dumb ideas to go through
I'd be very interested if your post contains an OpenPGP-CA review. I'm more familiar with "traditional" ways and that project looked very interesting to me.
What do you want to know? It's quite easy to set up a new CA, and all mainstream browsers have (albeit crappy) user interface for adding them.
The root ca installation is the boring part, installing a local Let’s Encrypt instance is much more fun
I never knew about CHAOS records. I'll have to look more into them. Thanks for the info!
A possibly needless clarification: The DNS is organised by class, name, and then type. Each class is a seperate space, so ycombinator.com in the IN (Internet) class and ycombinator.com in any other class aren't necessarily the same entities. Types can also be class specific, for example A in the IN class is different to A in the CHAOS class. Types may also only be defined in specific classes like SRV (amongst others) in IN. (Aside: this model is why CNAMEs can't coexist with other records.)
There’s also Hesiod (HS) records: https://jpmens.net/2012/06/28/hesiod-a-lightweight-directory...
I'm pretty sure CHAOS just gets used because all the names in class IN have potential meaning to other systems --- you can't just make up random IN names, because you could be screwing up someone else's domain (unless you tediously nest your made-up names under your own domain). But there's no risk of that with CHAOS, so it's a free-for-all for random DNS features.
You'd use a new class, like "RANDOM" or something, except that no deployed DNS software knows about that class.
You'd use a new class, like "RANDOM" or something, except that no deployed DNS software knows about that class.
There's private use ranges for classes and types. They don't have specific mnemonics but you can use the generic ones (eg: CLASS65280 and TYPE65280).
CHAOS probably gets used most because that's what BIND happened to do.
CHAOS probably gets used most because that's what BIND happened to do.
I just sort of assume it's because `dig` already has the string mapped. But maybe people just like typing "chaos".
It's crazy how HN, within the space of a decade, went from clamoring for this kind of thing to shitting on it at every turn.