In this post, we’ll explore DNS over TLS (DoT) and DNS over HTTPS (DoH).
DoT and DoH were invented to address privacy concerns associated with cleartext DNS requests. By encrypting the DNS request, privacy is significantly improved for the user, especially as TLS cleartext hostname observables are phased out in TLS 1.3. Though both provide similar capabilities, DoH can be more straightforward to make use of in comparison to DoT, as speaking json+https is very easy. It is also easier to camouflage amongst other seemingly innocuous HTTPS requests, passes through proxies, and is much more prevalent in the wild.
The Protocols
Both DNS over HTTPs and DNS over TLS wrap DNS requests within TLS streams. However DNS over TLS runs the binary DNS protocol over the TCP socket. DNS over HTTPS, as the name implies, encapsulates the DNS request in an HTTPS request. Before examining DoT and DoH, it’s important to take a quick look at DNS itself.
DNS
Recall that in DNS the client encodes a query for a domain name into a cleartext UDP datagram, and sends the message to its configured resolution server. This resolver determines the corresponding value associated with the name (perhaps contacting multiple authoritative name servers in the process). It then returns the answer in a cleartext UDP response to the client. This response is typically an A or PTR record. Armed with the response, the client can now connect to the desired system via its IP address. Zeek has a built-in DNS analyzer that logs all requests and responses it observes. This method of name resolution provides minimal privacy and maximum defender observability.
DoT
DNS over TLS is specified in RFC 7858. Basically, the UDP payloads from the DNS protocol are directly encapsulated in TLS-over-TCP. DoT is simply DNS, over a secure transport, wrapped in a TCP connection. Because it uses a single port, it can more easily be blocked by network controls.
DoH
DNS over HTTPS, defined in RFC 8484, is something different entirely. Though various forms of DNS over HTTP had been specified before, RFC 8484 is the most comprehensive, detailing the specific endpoints and interfaces to be used over HTTPS. One prescription from RFC 8484 is that compliant DNS over HTTPS must be served over HTTP2. Mainstream DOH servers support two methods of name resolution:
The binary format is similar to DoT in that it encapsulates and encodes a binary DNS request. This format encodes a DNS request packet in an HTTP POST request’s body, and transmits the request to the server. It receives a similarly encoded response from the server. If DoT is the most similar to the original DNS protocol, this binary payload form of DoH would take a close second.
JSON API
The JSON-encoded format is different compared to the Binary Payload. It’s a basic JSON API, that receives an unencoded request and request type, and returns back a JSON encoded recordset.
Providers and clients
Currently, the lion’s share of DNS over HTTPS is served by Cloudflare and Google. However, there are many other providers. A short list maintained by the cURL authors is available here. There are many DoH / DoT clients, including local DNS proxies, browsers, and malware. Though the original DNS protocol didn’t support the concept of “connections”, as it was UDP, both DoT and DoH support reuse of server connections to query as much as desired per connection. In practice, the browsers make use of this functionality, but many client libraries do not.
Browsers
Many popular browsers support DoH, including:
Currently, Chrome and Firefox enable DoH by default in some cases. Chrome rolled DoH out to a percentage of its users, and enabled “same provider auto upgrades” which switch you to DoH if your DNS provider supports it. Firefox automatically enables DoH, but falls back to DNS if DoH fails, or if users or administrators disable it.
Malware
Local DNS Proxies
Dual Use
As with all privacy enhancing technology, there are tradeoffs for network defenders. DNS logs are a powerful tool for detection and response, and DoT (and especially DoH) can be abused for malicious purposes. Even if you were to block all known DoH providers, a stealthy DoH request can blend in really easily against the rest of your HTTPS traffic, making it a powerful tool in an adversary’s kit. It’s worth explicitly stating that traditional DNS based block lists will no longer function.
Why this matters
Even in 2020, DNS is a very popular form of discovery and C2 for malicious implants. DNS over HTTPS is an effective technique for denying defenders observability of this surreptitious communication channel. However, legitimate activity will be blocked if networks administrators take a too heavy-handed approach in mitigating the newly introduced risks. Worse, detecting and blocking DoH generically is non-trivial, and using DoH especially on a non-standard server would provide a layer of obscurity over “vanilla” DNS resolutions. As all that is required is the ability to make HTTPS calls, integrating DoH will likely grow more popular among malware authors (it’s already lightly in the field, as sketched above).
Here at Corelight we are developing approaches to identify DoH traffic and to surface potentially suspicious activity. This effort is part of our broader “encrypted traffic insights” work, extending some of the techniques we previously used with SSH to TLS. In our first offering, we will be detecting and flagging well-known DoH providers in the SSL log. We plan to share more about our more generic detection approaches in future blog posts.
Editor’s Note – Oct. 15, 2020: For more information on DNS over TLS and DNS over HTTPS, check out the Forrester Report: Maintain Your Security Visibility In The TLS 1.3 Era (published July 2020).