Cloud Hosting

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.

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:

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.

Figure 1 Two-stage process for factoring in operational risk when determining how to address information protection objectives for a DNS exchange.

This process can readily be applied to develop guidance for each exchange in the DNS resolution ecosystem.

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.

Figure 2 Three DNS resolution exchanges: (1) resolver-to-authoritative at the root and TLD levels; (2) resolver-to-authoritative at the SLD level (and below); (3) client-to-resolver. Different information protection guidance applies for each exchange. The exchanges are shown with qname minimization implemented at the root and TLD levels.

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:

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.

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:

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.

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:

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.

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."

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.

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.

The rest is here:
A Balanced DNS Information Protection Strategy: Minimize at Root, TLD; Encrypt When Needed Elsewhere - CircleID