CISA's Encrypted DNS Guideline: A DNS Revolution?

May 16th marks a curious day in history: In 1966, China's Cultural Revolution began with the "May 16th Notice," an event that rocked the nation. This year, on the same date, CISA released a groundbreaking guideline on Encrypted DNS that could significantly reshape the internet landscape. While the impact hopefully won't be as devastating as the Cultural Revolution, the implications are undoubtedly huge. Let's break down what this means for us.

CISA's guideline has three major requirements, ideally implemented in this order:

1. Use Protective DNS (PDNS)

This is a DNS server with a new trick up its sleeve: the ability to distinguish malicious domain names from safe ones. Beyond the traditional role of resolving domain names to IP addresses, PDNS actively analyzes queries and can even intercept potentially harmful lookups. This means there needs to be a way to pass threat intelligence to the PDNS servers.

2. Block Unauthorized DNS (servers)

This means restricting clients to a set of approved DNS servers. While this might seem straightforward, the rise of encrypted DNS (DoH, DoT, DoQ) adds complexity. These protocols encrypt DNS traffic and use different ports (TCP/443, TCP/853, and UDP/443, respectively), making it harder to block at the network level.

3. Use Encrypted DNS

To counter the blocking issue, CISA recommends agencies implement their own encrypted DNS and reconfigure applications and operating systems to use it. This is a complex undertaking, but it could offer stronger security and privacy in the long run. Worth noting is, in the Appendix of the document, CISA called out all the popular applications and operating systems that have Encrypted DNS enabled by default and could bypass security policies (it includes basically everything, except the Safari browser). I’ve been trying to bring attention and awareness to this for years, and I am glad to see CISA doing the same.

Sample Design from CISA

The document even provided a sample (obviously simplified) design to show where these components would be placed on the network. What stood out to me is that they chose to place Protective DNS (PDNS) service on the “up stream”, rather than enabling that at the on-premise locations (i.e. closer to the users).

What Does This Mean for the Enterprise?

So, what can enterprise operators take away from this? While they might not have a pre-approved list of DNS servers like government agencies, the principle of controlling and securing DNS resolution is crucial. At the very least, enterprises should consider blocking unauthorized outbound DNS queries, limiting them to a few trusted servers. This, combined with protective DNS and a gradual adoption of encrypted DNS, can significantly bolster an organization's defense against DNS-based attacks.

Conclusion

This guideline is undoubtedly ahead of its time, much like the 2008 OMB memo mandating DNSSEC adoption for federal agencies. While ambitious, it sets a new standard for DNS security and privacy. Only time will tell how quickly agencies will adapt and what the wider implications will be.