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:
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.
Which wouldn't have worked even if it worked.
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 .com servers. Which the recursive nameserver already knows when it has the address of the .com 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.
Even in the rare case when the recursive nameserver doesn't have the address of the .com 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.
Recursive servers do not need public root servers because you could run a root yourself at 127.0.0.99 and point recursive to it, or bootstrap recursive one with this data. Of course, you need full control of the recursive server to set it up this way.
Taking down all public root servers (all 1723 of them, according to public data) may have no impact on a properly set up recursive servers, because root zone is public and you can host it yourself.
We're not talking about taking down the root servers, we're talking about the root servers mitigating the attack by dropping requests for that specific .com domain name.
That would have no effect on any recursive resolver that had the .com nameservers cached, which is substantially all of them because it happens as soon as they resolve any other .com domain name. That happens immediately and continuously even for small nameservers.
You would have a window of under a second once every TTL (currently 48 hours for gtld-servers.net, the nameservers for .com) between when the cached entry expires and when the next request for some other .com domain name comes in and refreshes it with a request to the root servers that they'd actually answer.
> dropping requests for that specific .com domain name
To do that, you have to accept client traffic, and parse the request. The only thing you "drop" is sending the response. It is not a very efficient mitigation mechanism, the DNS server would still become unavailable under pressure. It also hurts the victim, which is senseless.
DNS has a design flaw where the responses are often much larger than the requests, so dropping the response could reduce bandwidth use by a factor of ten or more.
> Even if a root server were to experience a major failure due to some sort of administration problem, there are twelve more.
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.
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.
Maybe for a query or two, but the problem sorts itself out.
Auth servers are very rarely running from a completely cold cache. Additionally most resolver software uses a system called scoreboarding where response times for each IP are recorded and it will prefer the fastest known nameserver for a query (some number of queries are still periodically sent to "slower" or unknown servers to gather metrics for them).
Clients never treat a system resolver as "broken." Most operating systems will round-robin the list of available recursive servers when there is a timeout before returning failure to the software. In the case of web browsers and such, they'll retry with a resolver operated by the browser vendor before admitting defeat.
Minor note: authoritative servers don't have caches. I think you meant recursive resolver (or better "caching resolver" which covers other types of resolvers that may also be caching, such as some stub-resolvers).
Traditionally (in the Berkeley code) the timeouts in the stub resolver in libc are 3x longer than the timeouts in the iterative resolver in the recursive server. I don’t think this is specified or that the RFCs even have much to say about timeout periods or retry counts.
The OpenNIC project [1] maintains an alternative DNS root and supports a few alternative TLDs: .bbs, .chan, .cyb, .dyn, .geek, .gopher, .indy, .libre, .neo, .null, .o, .oss, .oz, .parody, and .pirate.
My personal web page is available at http://pablo.rackham.pirate/ for users of this alternative root =). I don't have a TLS certificate for it thought, because it's not supported by Let's Encrypt (same problem with my .onion address, but it's less of a problem because traffic is e2e encrypted anyway over Tor).
Also, I don't know if there is any conflict with the new TLDs that were introduced by ICANN in 2015. I hope not :).
Oh I'm sure that if you're willing to pay for a certificate you can get one for pretty much anything you want. I was specifically talking about Let's Encrypt :).
Alternate roots are basically unusable. Either your domain names are universally accessible, or someone needs to follow specific instructions to use them, in which case why use AlterNIC or OpenNIC, when you could just give instructions that were specific to your chosen domain name?
Regardless of your grievences with ICANN, nearly universal consensus is almost certainly worth the price of using an ICANN delegated top level domain.
> Either your domain names are universally accessible, or someone needs to follow specific instructions to use them, in which case why use AlterNIC or OpenNIC, when you could just give instructions that were specific to your chosen domain name?
In theory there is a network effect. If it got popular enough, there is a possibility that major operating systems or browsers or recursive nameservers might start supporting one of the alternatives, which is never going to happen with a bespoke individual domain name.
That isn't necessarily incompatible with alternate domain name systems. If OpenNIC is registering names under .pirate and ICANN is aware of this then it can simply refrain from using .pirate as a TLD and you still have a unified namespace. It just happens by consensus rather than central authority.
If they would get along a little better then you might even have the ICANN root servers direct queries for those TLDs to the OpenNIC servers. It's not obvious what benefit is achieved by not doing this.
You may wish to read [RFC9476], which provides a solution for anchoring alternate name spaces in a way that provides both a signalling point for establishing that you've left the DNS and a way to prevent collisions with the DNS itself.
This doesn't help much to prevent collisions though, does it? An alternate namespace is obviously not going to use a TLD that already exists in the DNS, but it's much more likely to use one that exists in a different alternate namespace they've never heard of, since those will be more obscure and more likely to be missed. Putting them both under .alt does nothing to prevent this.
What you're really doing is reserving all of the as yet unallocated namespace to the DNS, privileging it over any alternatives which then have to use longer names. What you need is a mechanism for alternate namespaces to register their use of a particular subset of the global namespace against both other alternate namespaces and the DNS, at which point you wouldn't need to put them all under .alt.
They also immediately damaged that subset of the namespace:
> DNS stub and recursive resolvers do not need to look them up in the DNS context.
Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt, making it unsuitable for any namespace you would like intermediary resolvers to look up in an upstream server that supports them.
> This doesn't help much to prevent collisions though, does it?
It helps alternate name spaces not collide with the DNS. Without a registration system, it doesn't help alternate names spaces from colliding with each other (see .wallet for an example of this happening at the TLD space). There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place. EG, putting a centralized registration on top of decentralized architectures seems, um, weird at best. Supposedly the GNU naming system is creating a registration system that is optional to use. I don't know details about it and whether it's up and running yet.
The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also).
>> DNS stub and recursive resolvers do not need to look them up in the DNS context.
> Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt
So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay.
Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed.
The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD? If you want to truly revolutionize naming, then do something revolutionary and discard the current letters/numbers/etc separated by dots and create something entirely new and stop trying to look like the existing system. But that's an even harder problem because it also requires rewriting a lot of UI code. So most intentionally want to conflict with the DNS because it "helps them", theoretically, get more market space by hopefully believing that applications will suddenly be able to use an alternate naming space -- all without the user knowing they're in one?
> There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place.
Presumably what they hated was registration requirements.
If I need some namespace for my open source project, I can go and register a top level domain for it and all I have to do is pay $185,000 and shepherd it through a complex bureaucratic process and then pay $25,000/year forever. So corporations with more money than they know what to do with have their own top level domain that they don't even use for anything but small projects can't register one at all. Then there is nothing telling anyone else that they should pick a different TLD if they don't want a collision, and you create a default where new projects have to start out using unregistered namespace and then continue to use it as they start to get bigger.
Meanwhile you could have what amounts to an append-only wiki with some basic rules like "if your purpose needs multiple names, you get one TLD and put the rest under it" and "you have to register it again every 10 years if you're still using it". Then you wouldn't have two different things trying to use .wallet because one would have registered it first and the other would know to use something else.
> The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also).
This seems like it would be pretty easy to look up if there was a namespace registry (and is already going to make you suspicious of this if you don't recognize the TLD), and doesn't work for the many things that already exist and don't use .alt.
> So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay.
Except that the resolver might understand that alternate namespace. Suppose that OpenNIC started registering names under .alt, e.g. under .nic.alt, as this implies that they should instead of creating new TLDs. If they're the only ones using .nic.alt, recursive nameservers in general should be able to add the OpenNIC servers to their root hints and then be able to resolve those names, but now the stub resolvers will throw away the queries that might have succeeded.
> Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed.
And telling the stub resolvers to throw away the queries prevents that point from being in the upstream resolver. Most anything resolving names to IP addresses should be able to do that. You add support for it to e.g. your WiFi router or the recursive DNS resolver your company uses and then everything on your network can resolve those names.
> The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD?
Because they want to be supported by existing software. If your upstream DNS server is configured to support OpenNIC or Namecoin or what have you then you can just type those names into your unmodified browser or ssh client etc. and they get resolved.
There are many things that only want to provide an alternative to ICANN and don't have any need to provide an alternative to IP addresses or the way client applications issue name resolution queries.
I think this could go on for pages and pages more, and we can't get the entire industry to agree on the importance of any particular bullet point yet. I'd love to sit down face-to-face sometime and debate this endlessly, but I've done that with a lot of people on all sides already and there is no easy answer that any conversation has come to. It is never as easy as one side of the argument ever wants it to be.
> If I need some namespace for my open source project, I can go and register a top level domain
One common question here is: if you have an open source project, why do you need a TLD? Why is that special? the TLDs are designed into the DNS space and exceptions aren't cheap. Registering a domain under .org, or .horses is cheap compared to the $185k. And using something under .alt is free. Justifying the need for a TLD is difficult when there are other options.
>> The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD?
> Because they want to be supported by existing software.
That's exactly the point I was making: the goal is to get the cheap way out trying to register part of an existing landscape rather than inventing a new universe. If the new universe is that much better, then everyone will want to deploy it anyway. As the web browser market will tell you, their applications (the only ones that most people care about these days [not me, mind you]) update ever 3 months. Getting them on board with a new universe should be trivial! In fact some browsers already support alternate spaces. Green-slate designs are often much cleaner and better when people aren't trying to do a mix of revolutionary and evolutionary approaches.
> if you have an open source project, why do you need a TLD? Why is that special?
It's not really a matter of whether it's a TLD, though that makes more sense in this context because putting it under some existing TLD like .org would imply to most people that it isn't a separate namespace. And you can see how forcing their names to be of the form myboard.chan.example.horses is putting the alternative at an unnecessary disadvantage vs. just myboard.chan or even myboard.chan.nic when neither .chan nor .nic are existing ICANN top level domains.
You also want it to be designated as a separate namespace, because it is. That makes the stakes much higher than they are for an individual domain name so it shouldn't be possible to lose it in a divorce or to a stickup artist if someone fails to renew it etc.
> That's exactly the point I was making: the goal is to get the cheap way out trying to register part of an existing landscape rather than inventing a new universe. If the new universe is that much better, then everyone will want to deploy it anyway.
Of course they don't want to invent a new universe. Who is going to use a web browser that can only resolve names in a new namespace and can't resolve youtube.com or wordpress.org? And why would someone want that, instead of being able to do both?
To provide a practical example, Tor Browser can resolve both .onion sites and ordinary web pages. Then the .onion sites can link to ordinary ones -- or vice versa, if the ordinary site is inclined to provide a link that only works in Tor Browser.
An upstream nameserver couldn't do that because it onion sites don't have an IP address to put in the response for an ordinary browser, but Namecoin sites do. Which is why there isn't a separate "Namecoin Browser" -- you don't need one.
> As the web browser market will tell you, their applications (the only ones that most people care about these days [not me, mind you]) update ever 3 months. Getting them on board with a new universe should be trivial!
I detect that you're deploying sarcasm because you know that is non-trivial. But then I'm not sure what your point is supposed to be. Are you insisting that people do the thing you know makes their endeavor more likely to fail?
> Green-slate designs are often much cleaner and better when people aren't trying to do a mix of revolutionary and evolutionary approaches.
This seems like telling someone who wants to make electric cars that they're wrong to want them to work on the same roads as gasoline cars.
Why? Rerooting will just only cause problems to solve a solution that doesn’t need to be solved.
The only places that are offended by how America-centric DNS is, don’t actually care since they’re already blocking anything they don’t like.
It’s hard to even have a DNS Root in Europe with how many European countries have normalized internet censorship. NetzDG would have caused an actual implosion of America if it ever existed here.
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.
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.
Whoever bought the name on the blockchain is the owner within that decentralized DNS registry. If you don't like it, you can buy that same domain name on a different decentralized DNS registry (e.g. on a different blockchain) and try to use your influence to promote your users to use that one instead.
I don't recall ever signing a contract with any government agreeing to all these trademark laws we have today. Why should they have precedence over the laws of decentralized blockchains which people have chosen out of their own free will?
Do you mean acronym collisions? I think that might just be part of getting older; I started complaining about it around 30, but I am a bit of a complainer anyway.
Why? We do the same thing with file path for example, with / being both the root and the separator. In both cases you can think of the character as the separator if you prefer it to have a single role, and then the root is just the empty string.
Oh, or we could add drive specifiers (maybe letters for ease of typing?) and then a reserved character before the root path separator to signify the change in context.
I laughed, but wanted to acknowledge that the single tree filesystem is a pretty great invention. I like how the plan 9 ethos is "if it's a tree, it goes in the filesystem somewhere" dns.. in the filesystem. html dom? looks like a tree to me, in it goes.
And I think this is the fundamental problem with the windows registry. Because it sounds like a really great idea. "A dedicated database to store all configs in" However in reality it sort of sucks. I think this is because now you have a second strange tree that has different special access methods and usage.
An interesting functional distinction between the unix filesystem hierarchy and the DNS hierarchy. is that in the unix filesystem directories are distinct named entities and in DNS there is no such concept(closest you get are glue records)
Actually the root is a null (empty) label rather than "."; dots are delimiters of labels, there is an empty label after "." in FQDNs. See RFC 1034 Section 3.1.
I am not sure why you are being down voted, intuitively I would expect the exact opposite, and my colleague and I say "group dot" out loud as a shortcut when we mean "group dot myorg dot com" at work.
I run DNS servers for fun. But I also have a 1961 convertible that I drive around with missing floorboards and rusted rockers. I will never restore it.
Because we can't print NULL/"", it looks like a single dot at the end. But this single dot separate com from root label, which is empty "". We ommit this label and this dot.
https://www.icann.org/en/system/files/files/rssac-023-04nov1...
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:
https://www.icann.org/en/system/files/files/rssac-042-17may1...