9 ms·

The Top of the DNS Hierarchy

178 points by mrzool 3y ago

1vuio0pswjnm7 3y ago
It's 13 IP addresses but way more than 13 servers or 13 server locations. With anycast, more than one computer can have the same IP address.
deleted 3y ago
[deleted]
hardaker 3y ago
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: https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf 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-17may19-en.pdf https://www.icann.org/en/system/files/files/rssac-042-17may1...
teddyh 3y ago
> BIND used to stand for Berkeley Internet Name Domain Surely “Berkeley Internet Name Daemon”?
- WarOnPrivacy 3y ago
  I'm running into so many multipurpose acronyms lately I'm wondering if we shouldn't start nesting them or something. As an aside, why do you ” and not " ? App thing?
  - teddyh 3y ago
    " is an ASCII abomination, and should only be used when absolutely necessary.
    - deleted 3y ago
      [deleted]
  - silverquiet 3y ago
    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.
- rascul 3y ago
  > Surely “Berkeley Internet Name Daemon”? The Berkeley Internet Name Domain Server https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html
  - teddyh 3y ago
    I stand corrected.
- c22 3y ago
  named is the BIND daemon.
WarOnPrivacy 3y ago
> everything is a subdomain of something, even "rip" itself, which in a certain sense is a subdomain of the DNS root "." 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.
- p4bl0 3y ago
  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.
  - c0pium 3y ago
    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. Something like c:/dir_name could really take off…
    - packetlost 3y ago
      I find this snarky comment hilarious while also being disgusted at the implication
      - bombcar 3y ago
        www.example.com.c:
    - somat 3y ago
      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.
calvinmorrison 3y ago
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
- p4bl0 3y ago
  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/ 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 :). [1] https://www.opennic.org/ https://www.opennic.org/
  - bombcar 3y ago
    Weirdly enough apparently there are a few SSL cert issuers who will issue for .onion - maybe they would issue for OpenNIC.
    - p4bl0 3y ago
      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 :).
- overstay8930 3y ago
  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.
- 3y ago
jesprenj 3y ago
> 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.
- fanf2 3y ago
  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.
- mike_d 3y ago
  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.
  - hardaker 3y ago
    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).
spenczar5 3y ago
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!
- aftbit 3y ago
  Read more of computer.rip. It's all in this style.
  - pests 3y ago
    Seconded. I've read through the entire archive. He gets on some very interesting tangents and I've learned a lot of weird things.
- msla 3y ago
  I especially like his exploration of some odd classic rock radio stations: https://computer.rip/2021-01-23-classic-rock-radio.html https://computer.rip/2021-01-23-classic-rock-radio.html
zrm 3y ago
> 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.
- paulddraper 3y ago
  Surely there are a number of resolvers who have a cold cache. But yes, even taking down every root server (temporarily) has a limited effect.
  - zrm 3y ago
    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.
    - remram 3y ago
      > 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.
jongjong 3y ago
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.
- miniBill 3y ago
  How do you avoid squatting?
  - spacebanana7 3y ago
    Although there are some soft mitigations, it's still an issue for even the Ethereum Name Service https://discuss.ens.domains/t/domain-squatting/9189 https://discuss.ens.domains/t/domain-squatting/9189
  - deleted 3y ago
    [deleted]
  - jongjong 3y ago
    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?

178 points by mrzool 3y ago

It's 13 IP addresses but way more than 13 servers or 13 server locations. With anycast, more than one computer can have the same IP address.

deleted 3y ago

[deleted]

hardaker 3y ago

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: https://www.icann.org/en/system/files/files/rssac-023-04nov16-en.pdf 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-17may19-en.pdf https://www.icann.org/en/system/files/files/rssac-042-17may1...

teddyh 3y ago

> BIND used to stand for Berkeley Internet Name Domain Surely “Berkeley Internet Name Daemon”?

WarOnPrivacy 3y ago
I'm running into so many multipurpose acronyms lately I'm wondering if we shouldn't start nesting them or something. As an aside, why do you ” and not " ? App thing?
- teddyh 3y ago
  " is an ASCII abomination, and should only be used when absolutely necessary.
  - deleted 3y ago
    [deleted]
- silverquiet 3y ago
  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.
rascul 3y ago
> Surely “Berkeley Internet Name Daemon”? The Berkeley Internet Name Domain Server https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/5957.html
- teddyh 3y ago
  I stand corrected.
c22 3y ago
named is the BIND daemon.

WarOnPrivacy 3y ago

> everything is a subdomain of something, even "rip" itself, which in a certain sense is a subdomain of the DNS root "." 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.

p4bl0 3y ago
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.
- c0pium 3y ago
  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. Something like c:/dir_name could really take off…
  - packetlost 3y ago
    I find this snarky comment hilarious while also being disgusted at the implication
    - bombcar 3y ago
      www.example.com.c:
  - somat 3y ago
    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.

calvinmorrison 3y ago

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

p4bl0 3y ago
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/ 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 :). [1] https://www.opennic.org/ https://www.opennic.org/
- bombcar 3y ago
  Weirdly enough apparently there are a few SSL cert issuers who will issue for .onion - maybe they would issue for OpenNIC.
  - p4bl0 3y ago
    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 :).
overstay8930 3y ago
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.
3y ago

jesprenj 3y ago

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

fanf2 3y ago
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.
mike_d 3y ago
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.
- hardaker 3y ago
  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).

spenczar5 3y ago

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!

aftbit 3y ago
Read more of computer.rip. It's all in this style.
- pests 3y ago
  Seconded. I've read through the entire archive. He gets on some very interesting tangents and I've learned a lot of weird things.
msla 3y ago
I especially like his exploration of some odd classic rock radio stations: https://computer.rip/2021-01-23-classic-rock-radio.html https://computer.rip/2021-01-23-classic-rock-radio.html

zrm 3y ago

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

paulddraper 3y ago
Surely there are a number of resolvers who have a cold cache. But yes, even taking down every root server (temporarily) has a limited effect.
- zrm 3y ago
  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.
  - remram 3y ago
    > 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.

jongjong 3y ago

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.

miniBill 3y ago
How do you avoid squatting?
- spacebanana7 3y ago
  Although there are some soft mitigations, it's still an issue for even the Ethereum Name Service https://discuss.ens.domains/t/domain-squatting/9189 https://discuss.ens.domains/t/domain-squatting/9189
- deleted 3y ago
  [deleted]
- jongjong 3y ago
  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?