Information Protection for the Domain Name System: Encryption and Minification


This is the last in a multi-part series on cryptography and the Domain Name System (DNS).

In previous articles in this series, I have discussed a number of applications of DNS cryptography, many of which relate to Domain Name System Security Extensions (DNSSEC).

In this last blog post, I’m going to draw attention to another application that may at first seem the most natural, although not always the most necessary: ​​DNS encryption. (I also wrote about DNS encryption as well as minimization in a separate article on protecting DNS information.)

DNS encryption

In 2014, the Internet Engineering Task Force (IETF) commissioned the DNS PRIVate Exchange (dprive) working group to begin work on encrypting DNS queries and responses exchanged between clients and resolvers.

This work culminated in RFC 7858, published in 2016, which describes how to run DNS over Transport Layer Security (TLS), also known as DNS over TLS, or DoT.

DNS encryption between clients and resolvers has since gained momentum, with several browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the encrypted DNS deployment, and with other improvements such as oblivious DoH.

The dprive working group focused its attention on the resolver-authority exchange when it was redesigned in 2018. And in October last year, ICANN’s CTO office published its strategic recommendations for the root server. managed by ICANN (IMRS, i.e. the L-Root Server), an effort motivated in part by concerns about possible “privacy attacks” on the resolver-root connection.

From a cryptographer’s point of view, the prospect of adding encryption to the DNS protocol is naturally very interesting. But this perspective is not the only one that matters, as I have repeatedly observed in previous articles.

Balancing cryptographic and operational considerations

A common theme in this series on cryptography and DNS has been whether the benefits of a technology are enough to justify its cost and complexity.

This question was raised not only in my review of two new cryptographic advances, but also in my remarks on the motivation of two established tools to provide proof that a domain name does not exist.

Recall that the two tools, Next Secure (NSEC) and Next Secure 3 (NSEC3) records were developed because a simpler approach did not have an acceptable risk/benefit trade-off. In the simplest approach, to provide a relying party with assurance that a domain name does not exist, a name server would return a response, signed with its private key, ” does not exist “.

From a cryptographic point of view, the simplest approach would achieve its goal: a relying party could then validate the response with the corresponding public key. However, this approach would introduce new operational risks, as the name server would now have to perform online crypto trading.

The name server should not only protect its private key from compromise, but should also protect cryptographic operations from overuse by attackers. This could open another avenue for denial of service attacks that could prevent the name server from responding to legitimate requests.

The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which provided the ability to move the private key and cryptographic operations offline, into the name server provisioning system. Cryptography and operations have been balanced by this better solution. The theme now returns to see through recent efforts around DNS encryption.

Like the simpler initial approach to authentication, DNS encryption can serve its purpose from a cryptographic perspective. But the operational perspective is also important. As designers rethink where and how to deploy private keys and cryptographic operations in the DNS ecosystem, alternatives with better balance are a desirable goal.

Minimization techniques

In addition to encryption, research has been conducted on other, possibly lower-risk, alternatives that can be used instead of or in addition to encryption at various levels of DNS.

We call these techniques collectively minimization techniques.

Qname minimization

In “classic” DNS resolution, a resolver sends the same FQDN to a root server, top-level domain (TLD) server, second-level domain (SLD) server, and any other server in the chain of referrals, until it finally receives an authoritative response to a DNS query.

This is how DNS resolution has been practiced for decades, and it is also one of the reasons for the recent interest in protecting information about the exchange between resolver and authority: the FQDN contains more information than anything but the surname server. needs to know.

One such minimization technique, known as qname minimizationwas identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license for its qname minimization patents.)

With qname minimization, instead of sending the fully qualified domain name to each nameserver, the resolver sends only what the nameserver needs to answer the query or to refer the resolver to a names to the next level. This follows the principle of minimal disclosure: the resolver only sends the amount of information the nameserver needs to “do its job”. As Matt Thomas described in his recent blog post on the subject, nearly half of all .com and .net requests received by Verisign’s .com TLD servers were in a minimized form in August 2020.

Additional minimization techniques

Other techniques that are part of this new chapter in the evolution of the DNS protocol include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range evidence obtained in response to previous queries to determine on its own whether a domain name does not exist. This means the resolver doesn’t always have to ask the authoritative server system for a domain name it hasn’t seen before.

All of these techniques, along with additional minimization alternatives that I haven’t mentioned, have one important common feature: they only change how the resolver works during the resolver-authority exchange. They have no impact on the authoritative name server or other parties during the exchange itself. They thereby mitigate disclosure risk while minimizing operational risk.

The resolver’s exchanges with authoritative nameservers, before minimization, were already relatively less sensitive because they represented the aggregate interests of the resolver’s many clients.1. Minimization techniques further reduce sensitivity at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver always sends aggregated interests in FQDNs at the SLD level and below2, and may also include some customer-related information at these levels, such as the customer subnet extension. Lower levels may therefore have different protection objectives than higher levels.


Minification techniques and encryption provide DNS designers with additional tools to protect DNS information, tools that, when deployed with care, can balance cryptographic and operational perspectives.

These tools complement those I have described in previous articles in this series. Some have already been deployed on a large scale, such as a DNSSEC with its proofs of non-existence NSEC and NSEC3. Others are in various earlier stages, such as NSEC5 and Symbolic Requests, and still others are considering “post-quantum” scenarios and how to deal with them. (And there are still other tools that I haven’t covered in this series, such as Authenticated Resolution and Adaptive Resolution.)

Modern cryptography is about as old as DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and meet new security objectives. Although they have often moved forward separately, as this blog series has shown, they also have the ability to move forward together. I look forward to sharing more information about Verisign’s research in future blog posts.

Read previous posts in this six-part blog series:

  1. The Domain Name System: A Cryptographer’s Perspective
  2. Cryptographic tools for non-existence in the domain name system: NSEC and NSEC3
  3. New Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries
  4. Securing DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon
  5. Securing DNS in a post-quantum world: hash-based signatures and synthesized zone signing keys
  1. This argument obviously carries more weight for large resolvers than for small ones, and does not apply to the less common case of individual clients running their own resolvers. However, small resolvers and individual clients looking for additional protection retain the ability to send sensitive queries through a trusted large resolver or through a privacy-enhancing proxy. In our discussion, we mainly focus on large resolvers.
  2. In namespaces where domain names are registered at the SLD level, i.e. under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root via the effective TLD” and “below the effective TLD”. level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.

About Author

Comments are closed.