You may wish to additionally read the history of the Root Server System, which was written by the Root Server Operators and provides significant more context and facts about it's development:<p><a href="https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf" rel="nofollow">https://www.icann.org/en/system/files/files/rssac-023-04nov1...</a><p>Another helpful document that explains why the diversity of Root Server Operator organizations is a good thing can be found in this document as well:<p><a href="https://www.icann.org/en/system/files/files/rssac-042-17may19-en.pdf" rel="nofollow">https://www.icann.org/en/system/files/files/rssac-042-17may1...</a>
This is a wonderful piece of writing. Clear, interesting asides, a complex subject covered in detail, internal sub-dramas with actual suspense. In the SEO and LLM text age, when so much writing is just a thinly disguised marketing attempt, this is so delightful. More like this, please!
> I doubt they thought they'd take down the root servers, but it seems totally reasonable that they might have wondered if the root server operators would filter DDoS traffic based on the domain name appearing in the requests.<p>Which wouldn't have worked even if it worked.<p>When a recursive nameserver asks the root servers for the address of "916yy.com", the root servers are just going to direct it to the <i>.com</i> servers. Which the recursive nameserver already knows when it has the address of the <i>.com</i> servers cached, as would be the case >99% of the time, and would ask them directly instead of bothering the root servers to begin with.<p>Even in the rare case when the recursive nameserver doesn't have the address of the <i>.com</i> servers cached yet, that condition would last for approximately zero seconds before someone tries to resolve some other .com domain name and it gets cached, typically for at least a day.
> Even if a root server were to experience a major failure due to some sort of administration problem, there are twelve more.<p>This usually does not help in case of DNS. Let's say a resolver queries a root that does not reply. The resolver will time out after n seconds and then try another root server, but will not send any replies to the querying client. Therefore, the querying client has no way to know if it's the resolver that is broken or the upstream authoritative server and the querying client itself will timeout after m seconds and switch to another resolver, ignoring any possible later response from the first initialized query.<p>If m is larger or equal to n, the problem is aparent -- client will never know if the root is broken or the resolver, usually treating the resolver as such.
One thing that surprises me is that there isn't more competition in this space. Alternate domain name systems by the Post COMINTERN bloc or something
Bypassing the DNS system is trivial. All we need to do is write a browser extension with an input text box which connects to a blockchain and uses it to map custom names to IP addresses (with the mappings stored on-chain) and redirects the user to the IP address directly. The only centralized component is the initial peer discovery phase which requires some hard-coded seed IPs but you could have a large list and rotate the seed list frequently. Anyway, once set up, it would be fully decentralized... You could already do this by using any generic blockchain like Bitcoin. Just use transaction messages to store name-to-IP mappings.<p>The seed peer discovery issue is not a big problem once the network is above a certain size. Beyond a certain point, you could just ask someone from your local community for the IP address of a node. You just need one good node to be able to connect to the network.
> everything is a subdomain of something, even "rip" itself, which in a certain sense is a subdomain of the DNS root "."<p>Now that he's explained it, I'm annoyed that we use . to represent the root zone and to delimit between zones. Pick a lane already.