The IETF’s Discovery of Designated Resolvers
The Domain Name System (DNS) has played a key role in the Internet’s success. It was designed to be scalable and resilient to handle enormous growth. The DNS has also proven to be a strong control point used to identify and remediate threats as Cisco Umbrella (previously Cisco OpenDNS) has repeatedly demonstrated. As the industry seeks to strengthen privacy, it must find methods to do so that retain resilience or risk large outages. Used correctly, an emerging technology known as Discovery of Designated Resolvers (DDR) can facilitate secure discovery of resolvers. It’s a significant security feature and is the topic of this blog.
Introduction
DNS has scaled well to meet the needs of over four billion people since its inception in the 1980s. In that time, there has never been an Internet-wide failure of the service. That is thanks to the millions of caching resolvers and large numbers of root servers spread around the world, along with redundancy at every other level. This architecture is no accident; it represents a solid design combined with decades of experience by people globally handling the Internet’s evolutionary growth in both size and capability.
One of the most important capabilities of the DNS is its use as a control point. For example, if bad actors attempt to use the DNS as a command-and-control (C&C) channel between them and their bots, the good guys use the DNS to identify and block those C&C channels. In the case of the recent attack on Solar Winds, this meant blocking queries to [*]avsvmcloud[.]com. A key value of Umbrella and similar services is that they are backed by expertise and ongoing operations to identify such threats. With IoT devices using mechanisms such as Manufacturer Usage Descriptions, the DNS can restrict communications from devices to a known set of destinations. Another use of the DNS is as a security control point to block or redirect answers for known malware sites.
What Has Changed?
For the past few years, the industry has been working on standardizing the privacy of DNS queries. This is a capability that OpenDNS has offered for quite some time through DNSCrypt. DNS over HTTP (DoH), which OpenDNS also supports, encrypts queries and responses over a RESTful interface and transmits them over HTTP. This is a strong technological advancement. However, the DoH standard does not define how an application should choose the resolver. Until recently, there were two ways to discover a DoH server: attempt to access DoH on the resolver handed to the application by the operating system or use one provided by the application provider.
The first method involves a bit of a guessing game. When applications try to use DoH on existing resolvers, they attempt an HTTP request over port 443 to the resolver that they learn from the operating system. The request is tested to see if a valid response is received. This requires that the DoH capability be directly bound to the existing hosts that offer DNS over UDP port 53. While this might be a reasonable first attempt to bootstrap DoH, in the longer term these services may have different scaling qualities. In addition, if the version of HTTP changes, applications would have to determine this by trying one HTTP version and then another. Also, in general, it is not good to send requests that the other side might not expect to receive.
When non-cooperating applications or platforms choose their own resolvers, they bypass the DNS-based malware protections available to the IT administrator (illustrated in Figure 2). This circumvents the will of the user or administrator. If your resolvers are not seeing DNS queries from browsers, this may be what is happening. Moreover, if browser developers were to use a small number of DNS resolver services, one could reasonably expect the existing resolver infrastructure capacity to diminish over time due to lack of demand. This is where we begin to become concerned about overall system resilience. Many of these services on their own are highly resilient. But when they fail, they risk taking out a very large number of services for large portions of the population—at the same time. Because DNS is a fundamental service used by every application, we must pay close attention to this risk.
One key form of protection from these sorts of failures is choice. When enterprises and individuals have the choice of product, the risk of large-scale failures due to a monoculture is considerably diminished.
Enter Discovery of Designated Resolvers
The new proposal, known as Discovery of Designated Resolvers (DDR), provides a new way for clients to query locally designated resolvers for a record that indicates whether the DoH service is available. Either an application or the underlying platform can make use of DDR to locate a DoH resolver by first querying for a list of resolvers using a new DNS record called Service Binding (SVCB). SVCB works similarly to the highly tested, well-known service (SRV) record, but also allows for additional application parameters, such as Application-Layer Protocol Negotiation (ALPN) information for transport layer security (TLS). The current proposal offers several different approaches for clients to authenticate resolvers. One requires that a certificate contain an IP address. Another approach omits that requirement but requires that the IP address of the DDR-discovered resolver have the same IP address as the unauthenticated resolver. A third approach bases the resolver discovery on a name rather than an IP address. We expect these models to develop further as the DDR proposal matures.
DDR resolves both visibility and scalability concerns, avoiding guesswork by developers. The infrastructure can be exercised so that a large and thriving resolver ecosystem can continue to flourish, with queries and responses encrypted, and reduce the risk of concentration of resolver services. DDR also has the potential to reduce individual device configuration complexity that is handled today by mobile device managers. What is needed are a few new records in resolvers and appropriate certificates on the resolvers.
There are several issues that DDR needs to resolve, such as how to address scaling of large numbers of resolvers, and it sometimes requires validation of IP addresses in certificates. That is a mechanism with which we currently have limited experience at scale. It also often relies on unauthenticated processes to discover the IP addresses of the resolvers that need to be in those certificates. Also, how to securely identify resolvers in devices outside an enterprise environment needs a bit more consideration.
Moving Forward and What Cisco Customers Should Do Now
As currently envisioned, DDR is the best secure resolver discovery proposal to date, but we expect this entire solution space to continue to evolve. A list of DNS resolvers is just one critical element of network configuration that needs to be securely learned. There are many others. The key is to establish trust between the end device and the network infrastructure and then rely on that trust to receive configuration information.
How do we bootstrap that trust? That is another area that the industry needs to devote more time and resources to establish.
For our enterprise, industrial, and small business customers, Cisco’s recommendation is that administrators deploy a secure and reliable resolver service that provides a layered defense against exfiltration and BOTnets—for all devices at all times whether at home, work, or elsewhere. Combined with DNSCrypt or DoH, Cisco Umbrella offers a needed level of protection for safety, security, scalability, and stability. For more information about our offering see https://umbrella.cisco.com.
Because the stability and security of the Internet is an important topic, you may also wish to participate in this discussion hosted by the IETF. DDR will be discussed over the coming months and then submitted for approval. Participation in IETF activities is open to all and there is no cost to join the mailing list discussions.
Check out our Cisco Networking video channel
Subscribe to the Cisco Networking blog
CONNECT WITH US