The DNS root server system comprises 13 root servers (operated by 12 organizations) with a total of 1,378 instances all over the world. Despite continued efforts to improve its resiliency, accessibility and stability, there are still some issues that restrict its efficiency.
Decreasing the round trip time to root servers
The round trip time to the root servers is dependent on multiple factors, but particularly, the proximity of a root server instance and it being routed to in the most efficient way. While the first of these can be addressed relatively easily by installing an instance of the root server close by, the second is harder to address.
Routing determines whether the traffic to the root server from the last mile will reach the local instance or take the transit route to an instance further away. If the traffic is transiting to a server outside the economy, the result is increased latency and poor performance in the context of DNS resolution.
Case in point, in India, Netnod, which is a root server operator managing i-root-servers.net, has an anycast IPv4 node in Mumbai. A traceroute from AS9498 to i.root-servers.net shows that traffic is not hitting the local instance but taking the transit route (Figure 1).
Similarly, RIPE NCC is the root server operator managing the k.root-servers.net. Again, in India, there is an anycast node and IPv6 node in Mumbai and Noida. A traceroute from AS9498 to k.root-servers.net shows that traffic is not hitting the local instance but taking the transit route (Figure 2).
Increasing the resiliency of the root server system
In the context of the DNS, the primary intention of using IP anycast is to have the topologically closest server provide the answer. This model fails if there is suboptimal routing as seen in the examples of traceroute to the root servers above.
The additional benefit of using IP anycast is that considering optimal routing, in the event of a DDoS attack, the impact is limited in effect as it gets confined to certain areas. In the past, IP anycast has helped to mitigate attacks on the root server system where the attack became limited in scope to certain anycast instances of the root server and caused a saturation of network connections.
On the contrary, the Mirai botnet attack on Dyn Infrastructure also tells us that large-scale attacks can cause congestion across the anycast instances resulting in unavailability of services.
Finally, we get to a set of broader questions: How do we increase resiliency against a DDoS on the root server system? And since the root server system does not penalize abuse (period), should we continue abusing it?
A probable solution as proposed in RFC 8806 is to run a local copy of the full root zone on the loopback. What this essentially suggests is that the full root zone on the loopback will serve as an upstream to the recursive resolver and the recursive resolver should be able to validate the zone from the upstream using DNSSEC.
In order to implement this, you first need a copy of the root zone. The following root servers (Table 1) currently allow the transfer of the root zone using AXFR over TCP.
| Sl. No | Root Server Operator |
| 1 | b.root-servers.net |
| 2 | c.root-servers.net |
| 3 | d.root-servers.net |
| 4 | f.root-servers.net |
| 5 | g.root-servers.net |
| 6 | k.root-servers.net |
| 7 | lax.xfr.dns.icann.org & iad.xfr.dns.icann.org (L-root server) |
Table 1 — Root Server Operators that support the transfer of the root zone.
The process of manually pulling the root zone has an operational issue — you need to periodically check if the root zone has changed in the root zone copy at the upstream and then update the copy of the root zone configured to run on the loopback.
Even though RFC 8806 is informational, recursive resolver software such as ISC BIND, Unbound and Knot Resolver have built-in support.
Serving a local copy of the root zone can be configured by slaving the root zone and is as simple as uncommenting a few lines in ISC BIND 9.16.3 (Figure 3).
Adapted and updated from a post which appeared on Brainattic.in.
Swapneel Patnekar is a DNS geek, network engineer and researcher with interests in Unix systems, networking and security. He is also an APNIC Community Trainer and a RIPE Atlas Ambassador.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.