Now that the National Institute of Standards and Technology (NIST) has published a new version of the Secure DNS Deployment Guide, Special Publication (SP) 800-81 (SP 800-81r3), you may have several questions in mind, such as “How is this version different than version 2?”, “What do those changes mean for me?”, “What actions do I need to take?” and “What should I have for dinner?” (Wait, how did that last one get in there?)
If you have questions like these, then you are in the right place, because I’m going to walk you through some major changes between version 2 and version 3. As my esteemed colleague, Cricket Liu wrote when announcing the release of the draft, SP 800-81 “has been an indispensable document for DNS administrators both inside and outside the U.S. federal government since the publication of its original version in May 2006.” If you need a bit more historical context before digging in, there is another great blog entry from Jim Mozley answering some FAQs about the role of SP 800-81 that is well worth reading.
How Is Version 3 Different?
One thing that is immediately noticeable is that the new version is significantly shorter than prior ones (you’re welcome). When Cricket and I first had the opportunity to speak with Scott Rose, an author of all the prior versions, he expressed the desire to make the new version shorter, so we attacked the text aiming to inflict more than just a flesh wound. A key goal was to focus on strategic concepts instead of specific implementation details and refer to relevant protocol standards rather than restate everything in SP 800-81. A shorter way of saying this would be to shift to more of the “why” and “what” than the “how.”
In most cases, specific configuration details are left to the documentation of the software an organization happens to use, rather than included in the new SP 800-81. Given how quickly software changes (have you patched your MS servers this week?), it makes sense for a document like SP 800-81 to provide general direction that won’t require constant updates to keep pace with newer and (hopefully) better tools.
What’s New?
The new version expands beyond merely securing DNS infrastructure into how DNS can serve as a foundational security tool, especially in zero-trust environments. Some key topics covered are Protective DNS, encrypted DNS (e.g., DoT, DoH, and DoQ), and DNS hygiene. Let’s run through each of these briefly to provide a bit more color.
Protective DNS
A Protective DNS (“PDNS”—not to be confused with passive DNS’s “pDNS” acronym, sigh) system is one that uses DNS as a policy evaluation and enforcement point within a network. PDNS integrates threat intelligence into the DNS infrastructure as well as analytical evaluation of traffic to determine whether or not each DNS query should be resolved as-is or if different actions are necessary. Because a DNS query is the initiation point of nearly all network communications, PDNS is the ideal point to disrupt potentially malicious communications as early as possible. Given the current threat landscape, any organization with an Internet-connected network should be leveraging PDNS in some fashion.
Encrypted DNS
Since the prior version of SP 800-81, multiple standards for encrypted DNS have been developed. The three key approaches are DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). Each of these standards focuses on encrypting the DNS communications between client devices (i.e., stub resolvers) and their recursive DNS server (solving the “last mile” problem). While privacy was a leading focus of developing these technologies, they also protect those communications from tampering. However, there is a cost that comes with encrypting DNS communications: It can prevent network administrators from monitoring and filtering traffic, and it can also help threat actors more effectively hide their communications over DNS.
At the moment, DoT, DoH, and DoQ only address client-to-server communications, but there are efforts underway that may facilitate the use of these protocols for server-to-server communications (e.g., the DELEG record and authoritative DoT (ADoT)). Chances are, your users are already using encrypted DNS, because many modern web browsers come with this feature enabled. Encrypted DNS is here to stay, and organizations must plan for it within their environment.
DNS Hygiene
Unfortunately, DNS is one of those “hot potato” technologies that everyone wants to own but no one wants to take care of. If “cleanliness is next to godliness,” then neglecting your DNS is a surefire way to a special kind of tech hell. The concept of DNS hygiene shines a light on how failing to keep an organization’s DNS data as tidy as possible presents significant security risks. Managing the lifecycle of DNS data is a team sport, as is Internet security. It is everyone’s responsibility to ensure that all related DNS records are decommissioned alongside the systems they point to, so they don’t become stale DNS records.
By closely managing an organization’s DNS data, administrators can minimize the risk of threats due to lame delegations, dangling CNAMEs, and lookalike domains. Put the effort in today to keep your DNS records clean and tidy. Your future self will thank you.
What Should I Do Next?
If you haven’t already, download and review the new version of SP 800-81. For those portions that are applicable to your current environment, consider what gaps there are versus the recommendations. If you have questions, especially about how you could go about implementing some of the recommendations, reach out to your Infoblox solutions architect (SA) to start a discussion, and if the SA has questions, they know where to find me.
About Author
