Recent US Executive Order Calls for Encrypting DNS

The US Executive Order “Strengthening and Promoting Innovation in the Nation’s Cybersecurity”, published on January 17, 2025, calls for a number of measures to strengthen cybersecurity in the US. These include many generally accepted best practices, such as publishing ROA (Route Origin Authorization) records, paying attention to BGP leaks, and source address validation. The document also includes a number of recommendations for encrypting communications, including voice, video and … DNS.

The call for encrypting Internet traffic was a bit of a surprise, coming from the US government, but it apparently reflects the realization that there are pervasive network penetration and surveillance efforts across the Internet and that increasingly, even government communications on presumably protected networks may be vulnerable to these actors.

Sec. 4, Securing Federal Communications, of the Executive Order reads, in part:

(c) Encrypting Domain Name System (DNS) traffic in transit is a critical step to protecting both the confidentiality of the information being transmitted to, and the integrity of the communication with, the DNS resolver.

(i) Within 90 days of the date of this order, the Secretary of Homeland Security, acting through the Director of CISA, shall publish template contract language requiring that any product that acts as a DNS resolver (whether client or server) for the Federal Government support encrypted DNS and shall recommend that language to the FAR Council. Within 120 days of receiving the recommended language, the FAR Council shall review it, and, as appropriate and consistent with applicable law, the agency members of the FAR Council shall jointly take steps to amend the FAR."

This means that new US government procurement will include a requirement for encrypted DNS.

(ii) Within 180 days of the date of this order, FCEB agencies shall enable encrypted DNS protocols wherever their existing clients and servers support those protocols. FCEB agencies shall also enable such protocols within 180 days of any additional clients and servers supporting such protocols.

Possibly, agencies that haven’t yet may begin enabling encrypted DNS where it is available in existing systems.

What are the DNS encryption options?

Prior to the development of DNS encryption, users seeking privacy on the Internet used either VPNs or an onion, like the Tor network, to shield all their Internet traffic from view until it could be combined with and obscured by the larger volume of other user traffic. In the past five years, several encryption options that do not require a tunnel have been developed specifically for DNS traffic.

The ICANN SSAC produced a report that compared the two major DNS encryption technologies specified by the IETF: DNS over HTTPS (DoH), and DNS over TLS (DoT). DoT encrypts the stream from the stub resolver to the recursive resolver, but not from the recursive resolver to the authority. The logic is that there is enough traffic coming from the recursive resolver that the individual DNS queries are lost in the larger traffic flow. DoH was sponsored by cloud providers, again to encrypt traffic from clients to the resolver, but DoH is implemented in the browser. (There is a subsequent proposal for authentication to the authoritative server, called ADOT, which is not yet standardized, nor is it specified in this US Government EO.)

In this crude diagram, the (xxxxx) represents the encrypted portion of the DNS exchange.

DoT [client browser] — [stub resolver] (xxxxx) [resolver] — [authoritative server]

DoH [client browser] (xxxxx) [resolver] — [authoritative server]

In addition to protecting individual queries and the privacy of clients making those queries, encryption can also be used to protect zone transfers. In some applications, zone names may themselves include confidential information, such as client identity. The IETF standard for this is RFC 9103, referred to as “XoT”, for DNS Zone Transfers over TLS. This is not specifically mentioned in the recent Executive Order.

DNS Encryption With BIND 9

Since version 9.18, BIND supports both DoH (DNS over HTTPS) and DoT (DNS over TLS). The newest transport technology, DNS over QUIC (DoQ) is in active development on our BIND 9.21 branch. BIND 9.20 also supports the PROXYv2 protocol over both DoH and DoT.

CISA published “Encrypted DNS Implementation Guidance” back in April of 2024. This document recommends, in the case of BIND, use of DNS over HTTPS, as well as zone transfers over TLD (XoT). It also discusses the use of a proxy to terminate TLS on a separate machine within the protected core network.

Limitations of DNS Encryption

DNS encryption alone does not provide a complete privacy solution, if, as is very often the case, the DNS lookup is followed by an HTTP connection. This has been documented by many observers. One excellent presentation that illustrates the issues is “What Can You Learn from an IP?”, given at ANRW ‘19 by S. Patil & N. Borisov. This problem is being addressed, with the development of ESNI (encrypted server name indicator) and ECH (encrypted client hello), but it is worth noting.

Impact of Encryption on Operations

Besides the overhead that encryption places on the DNS server (one reason why some operators prefer to offload the TLS processing to a separate box in very busy deployments), the biggest objection to encrypting the DNS is that can make it far more difficult to identify and block abuse in the DNS, as well as complicating troubleshooting.

Some Reading on DNS Encryption

• ICANN SSAC SAC109: The Implications of DNS over HTTPS and DNS over TLS

• CISA Encrypted DNS Implementation Guidance

• DoH Support in BIND 9

• DNS Privacy at IETF 104, a blog post by Geoff Huston

• Centralized DOH is bad for privacy, in 2019 and beyond, a RIPE Labs blog post by Bert Hubert

• Security Control Changes Due to TLS Encrypted ClientHello, another RIPE Labs blog post by Kathleen Moriarty