Over the past several years, questions about how to protect information exchanged in the Domain Name System (DNS) have come to the forefront.
One of these questions was posed first to DNS resolver operators in the middle of the last decade, and is now being brought to authoritative name server operators: “to encrypt or not to encrypt?” It’s a question that Verisign has been considering for some time as part of our commitment to security, stability and resiliency of our DNS operations and the surrounding DNS ecosystem.
Because authoritative name servers operate at different levels of the DNS hierarchy, the answer is not a simple “yes” or “no.” As I will discuss in the sections that follow, different information protection techniques fit the different levels, based on a balance between cryptographic and operational considerations.
How to Protect, Not Whether to Encrypt
Rather than asking whether to deploy encryption for a particular exchange, we believe it is more important to ask how best to address the information protection objectives for that exchange — whether by encryption, alternative techniques or some combination thereof.
Information protection must balance three objectives:
- Confidentiality: protecting information from disclosure;
- Integrity: protecting information from modification; and
- Availability: protecting information from disruption.
The importance of balancing these objectives is well-illustrated in the case of encryption. Encryption can improve confidentiality and integrity by making it harder for an adversary to view or change data, but encryption can also impair availability, by making it easier for an adversary to cause other participants to expend unnecessary resources. This is especially the case in DNS encryption protocols where the resource burden for setting up an encrypted session rests primarily on the server, not the client.
The Internet-Draft “Authoritative DNS-Over-TLS Operational Considerations,” co-authored by Verisign, expands on this point:
Initial deployments of [Authoritative DNS over TLS] may offer an immediate expansion of the attack surface (additional port, transport protocol, and computationally expensive crypto operations for an attacker to exploit) while, in some cases, providing limited protection to end users.
Complexity is also a concern because DNS encryption requires changes on both sides of an exchange. The long-installed base of DNS implementations, as Bert Hubert has parabolically observed, can only sustain so many more changes before one becomes the “straw that breaks the back” of the DNS camel.
The flowchart in Figure 1 describes a two-stage process for factoring in operational risk when determining how to mitigate the risk of disclosure of sensitive information in a DNS exchange. The process involves two questions.
This process can readily be applied to develop guidance for each exchange in the DNS resolution ecosystem.
Applying Guidance
Three main exchanges in the DNS resolution ecosystem are considered here, as shown in Figure 2: resolver-to-authoritative at the root and TLD level; resolver-to-authoritative below these levels; and client-to-resolver.
1. Resolver-to-Root and Resolver-to-TLD
The resolver-to-authoritative exchange at the root level enables DNS resolution for all underlying domain names; the exchange at the TLD level does the same for all names under a TLD. These exchanges provide global navigation for all names, benefiting all resolvers and therefore all clients, and making the availability objective paramount.
As a resolver generally services many clients, information exchanged at these levels represents aggregate interests in domain names, not the direct interests of specific clients. The sensitivity of this aggregated information is therefore relatively low to start with, as it does not contain client-specific details beyond the queried names and record types. However, the full domain name of interest to a client has conventionally been sent to servers at the root and TLD levels, even though this is more information than they need to know to refer the resolver to authoritative name servers at lower levels of the DNS hierarchy. The additional detail in the full domain name may be considered sensitive in some cases. Therefore, this data exchange merits consideration for protection.
The decision flow (as generally described in Figure 1) for this exchange is as follows:
- Are there alternatives with lower operational risk that can mitigate the disclosure risk? Yes. Techniques such as qname minimization, NXDOMAIN cut processing and aggressive DNSSEC caching — which we collectively refer to as minimization techniques — can reduce the information exchanged to just the resolver’s aggregate interests in TLDs and SLDs, removing the further detail of the full domain names and meeting the principle of minimum disclosure.
- Does the benefit of encryption in mitigating any residual disclosure risk justify its operational risk? No. The information exchanged is just the resolver’s aggregate interests in TLDs and SLDs after minimization techniques are applied, and any further protection offered by encryption wouldn’t justify the operational risk of a protocol change affecting both sides of the exchange. While some resolvers and name servers may be open to the operational risk, it shouldn’t be required of others.
Interestingly, while minimization itself is sufficient to address the disclosure risk at the root and TLD levels, encryption alone isn’t. Encryption protects against disclosure to outside observers but not against disclosure to (or by) the name server itself. Even though the sensitivity of the information is relatively low for reasons noted above, without minimization, it’s still more than the name server needs to know.
Summary: Resolvers should apply minimization techniques at the root and TLD levels. Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges.
Note that at this time, Verisign has no plans to implement DNS encryption at the root or TLD servers that the company operates. Given the availability of qname minimization, which we are encouraging resolver operators to implement, and other minimization techniques, we do not currently see DNS encryption at these levels as offering an appropriate risk / benefit tradeoff.
2. Resolver-to-SLD and Below
The resolver-to-authoritative exchanges at the SLD level and below enable DNS resolution within specific namespaces. These exchanges provide local optimization, benefiting all resolvers and all clients interacting with the included namespaces.
The information exchanged at these levels also represents the resolver’s aggregate interests, but in some cases, it may also include client-related information such as the client’s subnet. The full domain names and the client-related information, if any, are the most sensitive parts.
The decision flow for this exchange is as follows:
- Are there alternatives with lower operational risk that can mitigate the disclosure risk? Partially. Minimization techniques may apply to some exchanges at the SLD level and below if the full domain names have more than three labels. However, they don’t help as much with the lowest-level authoritative name server involved, because that name server needs the full domain name.
- Does the benefit of encryption in mitigating any residual disclosure risk justify its operational risk? In some cases. If the exchange includes client-specific information, then the risk may be justified. If full domain names include labels beyond the TLD and SLD that are considered more sensitive, this might be another justification. Otherwise, the benefit of encryption generally wouldn’t justify the operational risk, and for this reason, as in the previous case, encryption shouldn’t be required, except in the specific purposes noted.
Summary: Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names or client-specific information. Otherwise, they should not be required to implement DNS encryption.
3. Client-to-Resolver
The client-to-resolver exchange enables navigation to all domain names for all clients of the resolver.
The information exchanged here represents the interests of each specific client. The sensitivity of this information is therefore relatively high, making confidentiality vital.
The decision process in this case traverses the first and second steps:
- Are there alternatives with lower operational risk that can mitigate the disclosure risk? Not really. Minimization techniques don’t apply here because the resolver needs the full domain name and the client-specific information included in the request, namely the client’s IP address. Other alternatives, such as oblivious DNS, have been proposed, but are more complex and arguably increase operational risk. Note that some clients use security and confidentiality solutions at different layers of the protocol stack (e.g. a virtual private network (VPN), etc.) to protect DNS exchanges.
- Does the benefit of encryption in mitigating any residual disclosure risk justify its operational risk? Yes.
Summary: Clients and resolvers should implement DNS encryption on this exchange, unless the exchange is otherwise adequately protected, for instance as part of the network connection provided by an enterprise or internet service provider.
Summary of Guidance
The following table summarizes the guidance for how to protect the various exchanges in the DNS resolution ecosystem.
In short, the guidance is “minimize at root and TLD, encrypt when needed elsewhere.”
| DNS Exchange | Purpose | Guidance |
|---|---|---|
| Resolver-to-Root and TLD | Global navigational availability | • Resolvers should apply minimization techniques • Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges |
| Resolver-to-SLD and Below | Local performance optimization | • Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names, or client-specific information • Resolvers and SLD servers (and below) should not be required to implement DNS encryption otherwise |
| Client-to-Resolver | General DNS resolution | • Clients and resolvers should implement DNS encryption on this exchange, unless adequate protection is otherwise provided, e.g., as part of a network connection |
Conclusion
If the guidance suggested here were followed, we could expect to see more deployment of minimization techniques on resolver-to-authoritative exchanges at the root and TLD levels; more deployment of DNS encryption, when needed, at the SLD levels and lower; and more deployment of DNS encryption on client-to-resolver exchanges.
In all these deployments, the DNS will serve the same purpose as it already does in today’s unencrypted exchanges: enabling general-purpose navigation to information and resources on the internet.
DNS encryption also brings two new capabilities that make it possible for the DNS to serve two new purposes. Both are based on concepts developed in Verisign’s research program.
- The client can authenticate itself to a resolver or name server that supports DNS encryption, and the resolver or name server can limit its DNS responses based on client identity. This capability enables a new set of security controls for restricting access to network resources and information. We call this approach authenticated resolution.
- The client can confidentially send client-related information to the resolver or name server, and the resolver or name server can optimize its DNS responses based on client characteristics. This capability enables a new set of performance features for speeding access to those same resources and information. We call this approach adaptive resolution.
You can read more about these two applications in my recent blog post on this topic, Authenticated Resolution and Adaptive Resolution: Security and Navigational Enhancements to the Domain Name System.
