For many years, APNIC has supported the installation of instances of DNS root servers in our region. Locally available root servers improve the speed of certain DNS operations, and can also help the root server system to maintain service even when under heavy attack. Since 2002, we have assisted or sponsored at least 29 servers in 21 economies.
While this program has been effective, the ongoing growth of the Internet raises the question: is there a better way? Is there a way that DNS resolvers could be less dependent on root servers in order to do their work? If this were possible, and we could reduce the load placed on root servers by resolvers, then we may be able to avoid endless scaling of the root server system as the Internet continues to grow.
APNIC is supporting the Internet Systems Consortium (ISC) to incorporate code changes to BIND, ISC’s open source DNS software, that will achieve this for DNS resolvers that use BIND. APNIC will sponsor the development of this functionality — based on the recently published RFC 8198 (July 2017) — in the next major version of BIND, expected to be ready by early 2018.
APNIC and ISC expect the result to be a faster global DNS service, and significantly improved resilience of the DNS to attacks on the root server system.
How would it work?
RFC 8198 specifies a way in which DNS resolvers can cache and reuse DNSSEC NSEC records which effectively identify “gaps” in the namespace of a DNS zone. This allows recursive resolvers to create authoritative NXDOMAIN (“non-existent domain name”) responses for the entire span of possible names that are identified by the NSEC record.
The result is that a recursive resolver will quickly “learn” the entire root zone, acquiring cached knowledge of the names that are in the root zone and, indirectly, of the names that do not exist. With this knowledge within its local cache, the resolver has no need to re-query a root server for non-existent names until the cache expiry time is reached.
Geoff Huston covered this topic in a February blog post, if you would like to learn more about the technical details.
What does this mean for the DNS?
According to studies of root server query data collected by DNS-OARC, around two-thirds of all DNS queries sent by DNS resolvers to root servers are “junk” requests for domains that do not exist. However, DNS resolvers using NSEC caching of the root zone do not need to query root servers to determine if a name does not exist. Therefore, if a large number of DNS resolvers around the world were using this functionality, then the DNS query load for root servers globally would drop dramatically.
Reducing the load on root servers makes them more resilient against DDoS attacks and makes the root server system more efficient and scalable. Resolvers using aggressive NSEC will not send junk DNS requests to root servers — as they may be requested to do during a DDoS attack — as they can simply resolve those malicious requests without passing them on to a root server.
The resolvers will benefit as well, as they will no longer need to cache an unbounded set of names that are not in the root zone (in the form of NXDOMAIN responses). A small collection of NSEC records can describe the entirety of non-existent names, reducing the load on the resolver’s local cache as well.
Hopefully, other vendors of DNS software will follow suit and introduce root zone NSEC caching into their products too. In this way, APNIC believes we can achieve a more sustainable solution to DNS resilience in the APNIC region and globally.
Learn more
Geoff Huston will deliver a keynote presentation on this topic at APNIC 44 next month. I hope you can join the session either at the event, or via the live video stream, which will be available on the APNIC 44 website.
Also, we’ll be inviting ISC to share updates on the APNIC Blog as the project progresses.
If you have any questions or comments on this initiative, please leave a comment below.
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.