|
About the author: Brian Dickson is a member of the DNS team at GoDaddy. This team is responsible for all internal and external DNS, including our DNS product (hosted authoritative DNS services), our corporate DNS domains (authoritative), and internal DNS resolution.
About this post: 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 travelers. 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.
Why does DNS need Security?
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.
DNSSEC: DNS SECurity extensions
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 real owner of the data signs 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 backward 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).
Why does DNS need Privacy?
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, led 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.
The first pair of protocols implementing this were DNS over TLS (“DoT”), and DNS over DTLS, published in RFC7858 and RFC8094 respectively.
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.
DoT vs DoH vs “Classic” DNS/TCP and DNS/UDP
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 comparatively 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 identifiable 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 the 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.
Several important changes are resulting from the DoH functionality as implemented, and from the proposed DoH operational models. Those include:
Things That Can Go Wrong (when using a public DoH resolver)
The DoH resolver may be less secure than the pre-existing system OS-selected DNS resolver.
This Is Not A Test
“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://cloudflare-dns.com/dns-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.
Conclusions
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.
May enable bad actors to exfiltrate data over DNS.
It may even be necessary to deploy advanced “Menace in the Middle” (MitM) solutions to decrypt and inspect all HTTPS traffic exiting your network.
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 the 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).
A version of this post was originally published in the GoDaddy Engineering blog.
Sponsored byRadix
Sponsored byCSC
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byDNIB.com
Sponsored byVerisign
The Chromium Blog has some information on Chrome’s DNS-over-HTTPS experiment here: https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html
Please read the blog for details, here are some excerpts :
“With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active.
More concretely, the experiment in Chrome 78 will check if the user’s current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider. If the DNS provider isn’t in the list, Chrome will continue to operate as it does today. “
and
“By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work. If DoH fails, Chrome will revert to the provider’s regular DNS service. Opting-out of the experiment will be possible from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.”
Note that this is different to what is said in the article (“At least two browser vendors (Firefox and Chrome) have announced an intent to override whatever system DNS resolver choice may be present, with their own list of public DNS resolvers (including a default choice for each vendor), ...”