Doomsday and the DNS resolution
Last month I did a short webinar with Indian ISPs talking about DNS servers in detail. The idea of the session was to make network engineers from fellow ISPs familiar with root DNS servers, DNS hierarchy, anycast etc. As we went through slides it was clear from RIPE Atlas data that Indian networks are not reaching local DNS servers due to routing! (Data from RIPE Atlas here).
This may come as a surprise for policymakers (where there seem to be ongoing discussions around how India can have its own root DNS servers even though) we are not hitting existing local root DNS instances. Anyways does that statement of having own root DNS servers even possible?
First about the current servers referred to as Root DNS servers
- Essentially 13 public-facing systems with thousands of servers using anycast act as “authoritative” for the root DNS zone.
- More precisely these are secondary/slave authoritative DNS nodes and are synced to master DNS servers hosted with the respective root DNS operators. Those 13 servers which act as master further are synced to a sort of hidden master cluster administered by ICANN.
- The primary server (cluster) where entries are changed is hidden from the world for good technical reasons like avoiding a massive DDoS attack or hacking attempts.
- Thus root server operators are essentially running slave/secondary authoritative server for the root DNS zone and ensure that they copy they receive is simply distributed to thousands of slave/secondary DNS nodes across the world (map here) using common IPs which are hardcoded in all DNS software (as starting point for the resolution).
- Root DNS zone has been signed with DNSSEC back in 2010 and thus the zone files carries “cryptographic signatures” and hence that validates the authenticity of the data.
List of Root Servers with their IP & operators
| HOSTNAME | IP ADDRESSES | OPERATOR |
|---|---|---|
| a.root-servers.net | 198.41.0.4, 2001:503:ba3e::2:30 | Verisign, Inc. |
| b.root-servers.net | 199.9.14.201, 2001:500:200::b | University of Southern California, Information Sciences Institute |
| c.root-servers.net | 192.33.4.12, 2001:500:2::c | Cogent Communications |
| d.root-servers.net | 199.7.91.13, 2001:500:2d::d | University of Maryland |
| e.root-servers.net | 192.203.230.10, 2001:500:a8::e | NASA (Ames Research Center) |
| f.root-servers.net | 192.5.5.241, 2001:500:2f::f | Internet Systems Consortium, Inc. |
| g.root-servers.net | 192.112.36.4, 2001:500:12::d0d | US Department of Defense (NIC) |
| h.root-servers.net | 198.97.190.53, 2001:500:1::53 | US Army (Research Lab) |
| i.root-servers.net | 192.36.148.17, 2001:7fe::53 | Netnod |
| j.root-servers.net | 192.58.128.30, 2001:503:c27::2:30 | Verisign, Inc. |
| k.root-servers.net | 193.0.14.129, 2001:7fd::1 | RIPE NCC |
| l.root-servers.net | 199.7.83.42, 2001:500:9f::42 | ICANN |
| m.root-servers.net | 202.12.27.33, 2001:dc3::35 | WIDE Project |
By looking at the list one can clearly say it’s primarily American organisations (mostly non for profit) running these and that is what likely brings the discussion of “Can we have our own root DNS server“. That might sound legit question if we think from the aspect of Indian policymakers who went from bringing in great organisations like ISRO to UIDAI. Ignoring the 512-byte limit and assuming if we can get the root DNS server managed by India, it still won’t add any benefit.
Here’s why:
- As described above – the current set of root DNS servers are simply secondary/slave DNS nodes running in hierarchical sync model from hidden masters. So if we add another node it would ideally do the same task and won’t be any different from other nodes. Taking worst possible case scenario – If during say War or any other instability, someone decides to remove reference to “in” in the root DNS zone, it will cause an impact across .in whether or not it’s a root, b root or a hypothetical Indian root DNS server.
- If such root DNS server runs as a cluster of master and starting point then the issue comes on how Indian networks will be able to reach rest of domain names via hierarchy? Indian DNS resolvers still need to find a way to resolve .com, .us, .co.uk, .anything. If we are talking about a totally different version of the internet for India then that’s a different case altogether.
- Most of the mission-critical networks like defence run on their own separate backbone disconnected from the internet and public-facing root DNS servers won’t have an impact on them.
But what about a possible doomsday scenario where imagine networks in India are 100% isolated?
Assuming there’s a major loss in the connectivity of submarine cable capacity to just everywhere. In such scenario will content hosted in India still work at the DNS layer? Answer depends. Let’s explore…
Let’s look at SOA of the root DNS zone:
anurag@devops01 ~> dig . soa +short a.root-servers.net. nstld.verisign-grs.com. 2020121401 1800 900 604800 86400 anurag@devops01 ~>
SOA – Start of Authority record here has a bunch of values starting with serial, refresh, retry, expire and minimum TTL. Let’s map the output we see above to these values as per BIND reference syntax.
Serial: 2020121401
Refresh: 1800
Retry: 900
Expire: 604800
Minimum TTL: 86400
Expire here defines the number of seconds after which secondary can stop responding if the master does not respond. So 604800 means 7 days. Effectively after 7 days the internet as we know, it will stop working in event of a major system failure where India networks are 100% isolated and there’s absolutely no connectivity for all the root DNS servers in India to reach their respective hidden masters to sync up the zone data. (SOA reference Wikipedia). Can ISPs do something, in that case, to still make things work? Well, depending on DNS software ISPs are using, they can inject hard references to TLDs including .com, .in etc. Which brings us to the next level of resolution which is TLD resolution.
anurag@devops01 ~> dig com. soa +short
a.gtld-servers.net. nstld.verisign-grs.com. 1607981978 1800 900 604800 86400
anurag@devops01 ~>
For .com the retry is also 604800 i.e a week. So .com domains will stop working after a week of such mass outage.
anurag@devops01 ~> dig in. soa +short
ns1.neustar.in. hostmaster.neustar.in. 1607981693 1800 300 1814400 1800
anurag@devops01 ~>
For .in ccTLD, that number happens to be 1814400 seconds / 21 days. And hence .in will work up to 21 domains of such mass outage and very likely even after that since .in ccTLD master would likely be in India hosted with Neustar.
So well 7 days – that’s the limitation we live in. And remember submarine cable is not the only possible connectivity. A possible IP transit over satellite via any of friendly country will get the system to work as well or simply to ask Indian ISPs to put a static zone entry for .in towards IN auth servers hosted within India.
What is more concerning is that Indian networks are not hitting locally hosted root DNS instances. Primarily it’s because of fact that telcos do not peer with root servers in India except the ones at NIXI. And the ones at NIXI – K root (NIXI Noida), I root (NIXI Mumbai) and F root (NIXI Chennai) does seem unstable. At the time of writing this post – my understanding is that only F root Chennai is up (and that too with some issues recently). K root is not announcing it’s IPv4 address in Noida (IPv6 only) and I root seems down in NIXI Mumbai.
