When an ISP’s DNS resolver starts up, it contains only information about how to bootstrap the DNS resolution process. Specifically, it only starts with a list of DNS service identities and addresses for where the ‘root’ of the DNS can be reached, also known as the Root Server System (RSS).
When a web browser queries the ISP’s resolver about where www.icann.org is, for example, the resolver must start from the root and first ask where .org is. It will subsequently ask .org’s nameservers for where icann.org is, and so on.
Fortunately, most ISP resolvers will cache the list of nameservers that handles .org and other TLDs for a day (typically). So when an email server wants to know where the mail server for ietf.org is, the resolver can bypass asking the root where .org’s nameservers are because it already knows (until the cache expires).
Normally, the DNS system works remarkably well with very little downtime. Sure, you may notice when a particular site is down and there have been some rare occurrences of even multiple popular sites going down simultaneously (such as during the 2016 attack on the Dyn DNS infrastructure), but in general, most authoritative servers deploy significant infrastructure robustness to counter issues with route failures, DDoS attacks and so forth. However, there are times when an ISP’s resolver is trying to reach an authoritative DNS nameserver and it will be temporarily unavailable.
Our ‘LocalRoot’ solution: pre-cache important DNS information
When authoritative servers are unavailable, an ISP’s cache will likely help ride out the random bumps that may occur in Internet DNS infrastructure availability. For the root server system’s information, RFC 8806 specifies another potential mechanism for functionally pre-caching the entire contents of the root zone at once by pre-filling a pseudo-cache before users even send the resolver a request.
My LocalRoot project at USC/ISI implements and extends RFC 8806 with a number of additional features:
Secured transfers with TSIG
The Transaction SIGnature (TSIG) security extension, defined in RFC 8945, allows DNS clients to request authenticated data transfers using a pre-shared secret key. TSIG is the de facto standard for transferring data between primary and secondary DNS servers.
Though not strictly needed when a zone is signed with DNSSEC, LocalRoot supports TSIG transfers to ensure the glue records in zones (which are not signed with DNSSEC) are securely transferred.
Support for other zones
The LocalRoot project was recently augmented to support the distribution of other zones besides the root zone. The purpose of RFC 8806 is to enable pre-fetching/caching of the root zone itself. However, the LocalRoot project is striving to enable resolver administrators to cache other zone data as well. At this point, LocalRoot supports the following zones:
- . (the root zone)
- root-servers.net (the name server records for the root zone)
- Arpa
- dnssec-tools.org
If you’re a zone owner and interested in having LocalRoot support pre-distributing your zone, please reach out to me at hardaker [at] isi [dot] edu. In general, zones that wish to join the LocalRoot project should be relatively static (changing a few times a day at most) and relatively small.
Automatic configuration generation
LocalRoot is designed to be as easily usable as possible. By filling out a web form with your resolver’s IP address and other information, LocalRoot takes care of generating the necessary configuration for your resolver.
Currently, LocalRoot is capable of auto-generating configuration files for the following DNS resolver software:
- Bind
- Unbound
- NSD
- Knot DNS
Give LocalRoot a try
When I first created LocalRoot in 2017, I enabled it for a week on the DNS resolver in my house. I then measured the number of requests being sent to one server within the root zone to see what effect it had. As figure 2 shows, the number of DNS requests sent to the root system went to effectively zero while LocalRoot is enabled. (LocalRoot is now always on in my house.)
If you’re a recursive resolver operator and wish to give LocalRoot a try, register your server, let it generate the necessary configuration file for you, and integrate it into your test and operational environments.
Wes Hardaker is a Senior Computer Scientist at the Information Sciences Institute.
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.