Brian Dickson is a member of the DNS team at GoDaddy. This team is responsible for all internal and exteral DNS, including our DNS product (hosted authoritative DNS services), our corporate DNS domains (authoritative), and internal DNS resolution.
This blog is intended to highlight concerns for anyone interested in security and privacy or who is responsible for managing software, networks, or DNS infrastructure, which includes ISPs, regulators, enterprises, personal (home) networks, power users, and travellers. It is intended to provide limited guidance for what to watch for, possible policies to respond to, and terminology for helping conversations on these subjects.
The Domain Name System (DNS) is both a protocol and a distributed database of information concerning hosts and services on the public Internet. The most common information provided are the IP (Internet Protocol) addresses of hosts and services (including both IPv4 and IPv6). Communication between internet-connected devices occurs over the Internet Protocol (IP), and always uses IP addresses.
DNS has scaled extremely well, handling the growth of the Internet for the last 35 years. Client systems make use of intermediaries known as “resolvers”, which do the bulk of the “look-up” work in DNS, and which implement caching to avoid duplication of look-ups. The actual data in DNS is hosted on what are known as “authoritative” servers. In addition, the namespace for DNS is hierarchical, with each level of the hierarchy only needing to serve/maintain information about the next level down in the “tree” of names.
When a browser wants to access a website, such as www.example.com, the browser asks the local operating system to look up that name. The local system then sends a request to one of the configured DNS resolver(s) and waits for the response which will be an IP address that the browser needs. The resolver checks its cache for helpful answers, and whenever it does not find the information it needs, it talks to the corresponding authoritative DNS servers to get what it requires. It starts with the “root” servers, who tell it where to find the “com” top-level domain servers. Then it asks the “com” servers about “example.com”, and finally it asks the “example.com” servers about www.example.com.
If a site is popular, the resolver will typically have the data in its cache and return it immediately. This, in turn, not only ensures the DNS system is not overloaded, but also significantly improves the performance for the World Wide Web.
The design of DNS included an important architectural decision: the transport protocol used is user datagram protocol (UDP). Unlike transmission control protocol (TCP), UDP is connectionless, stateless, and lightweight. In contrast, TCP needs to establish connections between end systems and guarantees packet ordering and delivery. DNS handles the packet delivery reliability aspect internally and avoids all of the overhead of TCP.
There are two problems this introduces. The first is that UDP has no way of knowing whether the UDP packet it receives was sent by the actual IP address of the server, or if the IP address was forged (“spoofed”) by someone else. This is because UDP is stateless and connectionless; there is nothing at the transport level protecting against spoofing.
The second problem is that DNS resolvers maintain a cache, which necessarily relies on trusting the answers it receives. This trust means that if an attacker succeeds in spoofing data towards a DNS resolver, then that data will be used repeatedly to provide forged answers to clients.
In 2008, a security researcher, Dan Kaminsky, presented a talk at the Black Hat conference on methods attackers could use to do this “cache poisoning” attack reliably and at scale. See The Great DNS Vulnerability of 2008.
The only long-term solution for the cache poisoning problem is to protect the data in the DNS system using cryptographic signatures. The specific kind of security required, which DNSSEC provides, is data integrity. This is an assurance, to an astronomical degree of certainty, that the data one receives is the same data that the owner inserted into the system.
The basic model of this is: if the data is signed by the real owner of the data, and the owner’s legitimacy in signing its data is itself signed by the parent in the hierarchy, the data validity can be traced back to a single “root of trust”. This was implemented in a series of updates to DNS, known collectively as DNSSEC, and documented in RFC4033, RFC4034, and RFC4035 with a number of subsequent additions and improvements.
Only DNSSEC can prove that the data a resolver receives is legitimate, and local systems must either blindly trust their resolver, or optionally can themselves validate DNSSEC-signed DNS answers. Performing this validation is moderate in terms of computational resource used by an end system. However, to do this, end systems require specific software upgrades, something that has not yet been done widely.
DNSSEC is backwards compatible with pre-DNSSEC DNS, and its use is optional. It is strongly encouraged, however, since the protections it provides are only available if it is enabled.
Additionally, DNSSEC Authentication of Named Entities (DANE) provides mechanisms for securely publishing associations between DNS host/service names and server certificates (RFC6698). DANE can be used for stronger validation of web server certificates (the primary use case). By linking the certificate for a server or service to DNS, the “rogue CA” problem can be eliminated via non-repudiation - only the domain owners’ certificate can pass the validation process. The limitations of DANE are that it requires DNSSEC, including DNSSEC validation, as well as native browser support.
DANE also enables the opportunistic encryption of server-to-server email connections (RFC7672), or the serving email public keys for end users via OpenPGP or S/MIME (using the OPENPGPKEY record type defined in RFC7929, and the SMIMEA record type defined in RFC8162).
The Internet originally grew out of a small community of research and education networks, built on top of a network which was itself experimental and funded by the government. Those original networks were small enough and few enough that it was reasonable to trust the network and those operating and using it.
While improvements in security have been added onto the applications and protocols in use on the Internet, there was still a fundamental expectation that only the network operators, such as ISPs, had access to the infrastructure of the Internet.
In 2013, Edward Snowden disclosed the existence of a variety of comprehensive global surveillance systems. See Global surveillance disclosures.
In response, the Internet Architecture Board of the IETF released RFC7258, which states:
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.
This in turn, lead to the requirement to protect DNS queries from surveillance on the “last mile” portion of the Internet, specifically between the local system (client) and the resolver, as detailed in RFC7626.
Separately, and subsequently, a DNS over HTTPS (“DoH”) standard was produced and published as RFC8484. The “S” in HTTPS refers to transport security, specifically the use of TLS (previously called SSL) to encrypt the HTTP traffic.
The four DNS transport protocols (DoT, DoH, DNS/TCP, and DNS/UDP) all support the underlying DNS protocol. The context in which we are specifically comparing these transport methods is the client-to-recursive communications channel. DNS resolution relies on recursive resolvers to do the “heavy lifting” of obtaining DNS answers. Clients are comparitively simple, and must send DNS requests to their respective resolvers. Thus, this channel is important from a privacy perspective, since it is used for host systems supporting personally identifiably users, such as laptops, desktops, mobile devices, and consumer devices such as gaming systems. DNS client queries are PII (personally identifiable information) that ties a user to a DNS query.
The recursive-to-authoritative channel is a separate concern. There, the recursive resolver acts on behalf of many clients. The resolver maintains a cache of DNS answers recently received, which is independent of which client requested the answer. Popular domains are mostly served from this cache, meaning very few client queries actually require the resolver to contact an authoritative server to get the answer on behalf of the client. Thus, the privacy concern is somewhat variable and/or diluted, depending on what specific domain is being queried, and how many clients each resolver has. More clients mean a higher probability that the resolver’s cache may provider answers (avoiding any resolver-to-authoritative traffic). A larger pool of concurrent resolution traffic makes correlation of clients to queries more difficult.
All four DNS transport protocols support DNSSEC in theory. In practice, the issue of whether DNSSEC is used and whether validation occurs is dependent entirely on the resolvers’ operators.
The main distinctions between the four protocols are their channel security (visibility to on-path observers), and their interaction with network administrators for monitoring and blocking of DNS traffic. Both DoH and DoT provide channel security, since the DNS traffic itself is encrypted for both. All three of DNS/UDP, DNS/TCP, and DoT, are compatible with network monitoring and blocking at an IP level (address and port). However, DoT does encrypt the actual DNS queries, so only the existence of a DNS server would be visible to an observer (or possible to block). Since DoH uses the same transport as HTTPS, it is (by design) not compatible with the network administrator’s monitoring and blocking, as there is no way to distinguish DoH from other HTTPS traffic.
The other areas of comparison between DoH and DoT are the proposed deployment profiles, changes to the host “stack”, and selection of DNS resolvers.
DoT was developed as an “upgrade” to client-resolver DNS communications. It was intended to operate on a dedicated port, specifically so that both the client and server agreed that communication would be TLS-only (encrypted). This avoided some of the early problems when older protocols attempted to do “opportunistic TLS”, via STARTTLS. By doing enforced TLS, many attack methods are impossible (e.g. downgrade attacks on the protocol). DoT was also intended to act as a drop-in replacement (or upgrade) to existing DNS clients at the system level, so that applications could continue interacting with the host operating system (OS) without requiring modifications. Thus, the whole application-OS-DNS part of the client stack was conceptually identical, including all of the security, deployment, and management mechanisms. While DoT was compatible with third party DNS resolvers, it was not specifically intended for them, and was effectively resolver-neutral. Theoretically, any DNS resolver could be upgraded to DoT, and likewise, any network operator could choose to allow or block DoT traffic to DNS resolvers to whom it did not want to allow access (e.g. so that internal DNS resolvers could be exclusively used, for enterprise DNS).
On the other hand, DoH has largely been developed by web browser vendors and developers, with the primary design and intent to be incorporated directly in the browser. This intentionally bypasses the host OS “DNS stack”, which manages DNS resolver choice, implements a host-wide DNS cache, and provides DNS service to all host applications.
There are several important changes resulting from the DoH functionality as implemented, and from the proposed DoH operational models. Those include:
“If this had not been a test, you would have been instructed where to tune in your area for news and official information.” - paraphrased EBS text
Browsers are already implementing DoH, although they do so as a “disabled” feature configurable via advanced user preference. This includes both Chrome (Google) and Firefox (Mozilla) browsers.
For Firefox, the code is present on releases since Firefox 62, and can be enabled and configured using the “about:config” method (browser bar entry), and looking for fields that start with “network.trr”:
For Chrome, the code is available in version 66, minus control via the User Interface (UI). From https://bugs.chromium.org/p/chromium/issues/detail?id=799753
You can enable DNS-over-HTTPS via a command line flag, e.g.
chrome.exe --enable-features="dns-over-https<DoHTrial" --force-fieldtrials="DoHTrial/Group1" --force-fieldtrial-params="DoHTrial.Group1:server/https%3A%2F%2Fcloudflare-dns%2Ecom%2Fdns-query/method/POST
(The above are Windows-specific instructions; presumably similar methods are available on other operating systems such as Linux and Mac OS X.)
By being implemented already, the malware bar has already been lowered considerably; malware would only need to make user-level changes to the browser preferences, to enable DoH and to change the specific DoH resolver. This would have the effect of bypassing all DNS-based controls and facilitating DNS-based malware C&C (command-and-control) communications which would no longer be visible or detectable. The scripting involved (to enable DoH and change resolver) is as close to trivial as can be imagined - it is the equivalent of writing “Hello world” into a file.
Non-Browser Applications for mobile devices which use DoH have already been discovered on both the Google Play and the Apple App stores.
If you have read this far, you may be concerned (to a greater or lesser degree) by some of what you have read. What you should do, or whether you need to worry, is probably largely a factor of your specific environment:
There are not a lot of good options for addressing any of these problems.
Given the general interest in DNS privacy, it may also be advisable to stand up your own DoT or DoH servers, or upgrade from regular DNS to DoT or DoH on your resolvers. This provides improved privacy to end users, and may discourage use of third party DNS resolvers operating on DoH.
Impacted parties may want to contact their vendors to express concerns. Other actions worth considering include joining DNS operator groups such as DNS-OARC, DNS standards development groups (IETF or RIPE), contacting representatives of their respective trade groups, or investigate other technical solutions (such as alternative browsers).
Geoff Huston’s blogs on DoH: