Editors’ Note: This article was originally featured in the March 2021 (Vol. 18, Issue 1) Verisign’s quarterly DNIB report. To access the full report, including a snapshot of Verisign data and domain name industry trends in global registrations from that quarter, or any historic quarterly report data, please visit our archive.

As the Domain Name System (DNS) enters its fourth decade, it continues to evolve to meet the ever-changing needs of its users and operators. Originally designed to promote connection above all else, in recent years there has been an increased focus within the DNS on confidentiality. Notably, DNS encryption has recently come to the forefront and has sparked many conversations about how and when it should be used.

Verisign's DNS Encryption Recommendation

Because of our role as a global provider of key internet infrastructure, Verisign is dedicated to a thorough and careful consideration of DNS encryption and related techniques.

We believe it is important to consider the operational needs of each level of the DNS separately. A “one size fits all” approach risks not fully meeting the unique security and operational considerations of all levels of the DNS, e.g. the root, top-level domain (TLD), second-level domain (SLD), and so forth.

Implementors have two main approaches for protecting the confidentiality of information exchanged within the DNS.

DNS encryption techniques cryptographically conceal the information and reduce the risk of disclosure to outside parties who do not have the decryption key. Encryption can improve confidentiality and integrity by making it harder for an adversary to view or change data. Such techniques are bilateral: both parties involved in the exchange must implement them, and both therefore take on the operational risk of doing so.

Minimization techniques, in contrast, decrease the amount of information exchanged and reduce the risk of disclosing sensitive information to both outside and inside parties. These techniques are unilateral: only the sending party takes on additional functionality.

After significant research and collaboration within the DNS community, Verisign currently recommends using minimization techniques at the root- and TLD-server levels and encrypting elsewhere when needed. Based on the current operational and cryptographic realities, this is a practical approach to balancing both confidentiality and availability of information exchanged within the DNS. A summary of this recommendation can be found in the table below.

Client-to-Resolver

Resolver-to-SLD and Below

Resolver-to-Root and TLD

Clients and resolvers should implement
DNS encryption on
this exchange, unless adequate protection is otherwise provided, e.g., as part of a network connection.

Resolvers and SLD servers should implement DNS encryption on their exchanges if sending sensitive full domain names, or client-specific information.

Resolvers should apply minimization techniques.

The rationale is straightforward: information exchanged at the root and TLD levels is by nature less sensitive, especially after minimization techniques are applied, yet is more critical to global navigation; the rest of the DNS below these levels depends on it. The risk-benefit tradeoff for DNS encryption is better justified in other parts of the DNS ecosystem where data is more sensitive and/or dependencies are more limited.

If this approach were followed, we could expect to see more deployment of minimization techniques on resolver-to-root and TLD exchanges; 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 with today’s unencrypted exchanges: enabling general-purpose navigation to information and resources on the internet.

Key Considerations in Verisign’s DNS Confidentiality Protection Recommendation

When formulating this recommendation, we considered three key objectives, which are critical for any proposed information protection strategy:

  • Confidentiality: Does it protect information from disclosure?
  • Integrity: Does it protect information from modification?
  • Availability: Does it protect information from disruption?


Any solution must carefully balance these three elements. Furthermore, we factored in the risk versus benefit of any technique proposed to achieve these objectives, using a two-fold approach depicted in Figure 1 below.

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

Looking Toward the Future: Authenticated and Adaptive Resolution

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 first, called authenticated resolution, adds an enhanced security control point and brings the DNS in line with zero-trust principles. Authenticated resolution allows a requester to identify itself to a resolver or name server that supports DNS encryption. The resolver or name server can then return a response to the requester depending on whether the requester is authorized to receive the response, or ultimately, access the resources associated with the response.

The second, called adaptive resolution, adds a new navigation capability to the DNS. With adaptive resolution the requester provides information that the user has agreed to share with the web server to which the user is navigating, such as the user’s preferences, the user’s device, the information that the user is ultimately looking for or the action that the user wants to perform.5 The resolver or name server then optimizes its response based on these additional details in order to both provide the best response and to minimize unnecessary subsequent transactions or computations.

Authenticated resolution and adaptive resolution can add to the functionality of the DNS at the places where DNS encryption is deployed, i.e. at the resolver-to-SLD (and below) and client-to-resolver exchanges, bringing new value to applications and end-users alike.

More from the DNIB

DNIB Staff | 9 min. read
Duane Wessels | 7 min. read