Two principles in computer security that help bound the impact of a security compromise are the principle of least privilege and the principle of minimum disclosure or need-to-know.

As described by Jerome Saltzer in a July 1974 Communications of the ACM article, Protection and the Control of Information Sharing in Multics, the principle of least privilege states, “Every program and every privileged user should operate using the least amount of privilege necessary to complete the job.”

Need-to-know is the counterpart for sharing information: a system component should be given just enough information to perform its role, and no more. The US Department of Health and Human services adopts this principle in the HIPAA privacy policy, for example, which states: “protected health information should not be used or disclosed when it is not necessary to satisfy a particular purpose or carry out a function.”

There may be tradeoffs, of course, between minimizing the amount of privilege or information given to a component in a system, and other objectives such as performance or simplicity. For instance, a component may be able to do its job more efficiently if given more than the minimum amount. And it may be easier just to share more than is needed, than to extract out just the minimum required. The minimum amounts of privilege may also be hard to determine exactly, and they might change over time as the system evolves or if it is used in new ways.

Least privilege is well established in DNS through the delegation from one name server to another of just the authority it needs to handle requests within a specific subdomain. The principle of minimum disclosure has come to the forefront recently in the form of a technique called qname-minimization, which aims to improve privacy in the Domain Name System (DNS).

Conventionally, when a requester wants to look up a DNS record associated with a domain name, it sends a query with the full domain name to one or more name servers, typically starting with the DNS root server. If the name server is “authoritative” for the domain name, it answers the query directly. If not, it may “refer” the requester to another name server that is either authoritative, or knows another server to ask. As an example, to resolve the domain name “www.example.com”, a requester may first query the root server, which may refer the requester to the name server for “.com,” which may in turn refer the requester to the name server for “example.com.”

This process is convenient because the requester can simply send the same query name or “qname” to each name server in a chain of referrals until one of them answers directly. However, the process does not generally follow the principle of minimum disclosure. For example, the root server doesn’t need to know the full domain name “www.example.com” to do its job in the process of DNS resolution; it just needs the last label of the domain name, i.e., the top-level domain (TLD) “.com.” The root server’s decision to refer the requester to the name server for a TLD only depends on whether the TLD has been established or “delegated” in the DNS, not on the other labels of the domain name, so the root server doesn’t need to know them.

With the qname-minimization technique, the domain name in a DNS query is constructed with the objective of reducing or minimizing the amount of information disclosed to each name server in the chain of referrals. The process can actually be quite subtle, because it’s not always clear how the administrative boundaries are set up between authoritative name servers. The root server’s boundaries are straightforward—they are based on delegated TLDs, just one label deep. Elsewhere in the DNS hierarchy, however, delegations may occur after just one label in some cases and after two (or more) in others, so minimization is not always as simple as just revealing one additional label to each name server.

Privacy has been a major theme of activity within the IETF since the discussion of “Internet hardening” and pervasive monitoring at the IETF 88 plenary meeting in November 2013. Verisign Labs researchers are co-authors in two recent Internet-Drafts motivated by this theme: Opportunistic Encryption with DANE Semantics and IPsec: IPSECA and TLS for DNS: Initiation and Performance Considerations. The drafts specify alternate methods for encrypting DNS query / response streams to prevent disclosure to external parties. Qname-minimization, covered in the Internet-Draft DNS Query Name Minimisation to ImprovePrivacy, may be considered a complementary method that reduces disclosure both to external parties and to name servers. It can be combined with either (or both) of the encryption-based methods.

Verisign encourages the development, standardization, and appropriate deployment of each of these methods. In support we’ve just announced our RAND licensing terms related to this proposed qname minimization method, an open, royalty-free license to intellectual property we hold related to qname-minimization, both to encourage further study and development, and in the event it becomes an adopted standard by the IETF.

Verisign also encourages the development of methods whereby a DNS resolver can indicate to a relying party that it supports one or more of these proposed privacy-enhancing techniques. There are a number of possible ways for a resolver to indicate its capabilities, which should be a good basis for discussion in IETF working groups and elsewhere.

We believe that qname-minimization is an important capability for DNS resolvers to offer. However, as with other positive changes, there are also potential “side effects” to consider.

Recall that when I stated that the root server doesn’t “need to know” the full domain name to do its job, I added the qualifier, “in the process of DNS resolution.”

From a system perspective, the root server and other authoritative name servers also arguably perform a second job as well, which is to help detect security threats. While not a formally required function, name servers’ analysis of DNS traffic patterns has become an important part of a “defense in depth” strategy for understanding security threats from multiple perspectives in a networked ecosystem. For this purpose, more information is generally better than less. For instance, if qname-minimization had been practiced historically, it may not have been possible to determine the potential impact of name collisions resulting from the introduction of new generic TLDs (gTLDs) at least not from root server data alone. The root servers would have seen the potentially colliding TLDs, but not the full domain names containing them, such as those potentially at risk in service-discovery protocols.

As another example, the remote code execution vulnerability recently announced by Microsoft was discovered in part based on analysis of the full domain names in queries to the root server system. Identified during the course of JAS Global Advisors’ ICANN-commissioned study on name collisions, the vulnerability, named JASBUG, became evident from “applying ‘big data’ analytical techniques to very large (and relatively obscure) technical datasets.” Although details of the analysis have not yet been published, simMachines—co-discoverer of the bug—has confirmed that the “analysis would have been partially impacted” if full domain names were not available at the root server system and that “other analysis will be fully impacted” if security researchers do not have another way to access this level of information.

Minimizing disclosure in the form of qname-minimization thus introduces another tradeoff: While enhancing privacy, it may also reduce visibility into security threats.

For this reason, while encouraging adoption of qname-minimization, Verisign also encourages research into the impact of this technique on authoritative name servers’ “second job” of detecting Internet security threats. If that job is significantly impacted, then it may also be necessary to develop new methods for sharing information within the DNS—such as those described in my previous blog post “The Why and How of DNS Data Analysis”—in order to restore the visibility that has been lost. Put another way, if information disclosure is reduced to the minimum needed for a name server’s first job, then much of its second job may need to be performed elsewhere in the system.

The principles of least privilege and need-to-know play out in many aspects of computing, and it’s good to see the renewed focus within DNS. The discussion also motivates reconsideration of the “jobs” that a name server performs, both explicit and implicit. Only with that perspective, can one answer the question: What does a name server need to do its job?