What’s up DOH!
The opinions expressed in this post are my own and not necessarily those of my employer
I first learned about DOH (DNS over HTTPS) about a year ago and have been wanting to understand how it works for a long time as I think it could affect many of the DNS detection in place for many organizations. Recently, I came across 12 Day of Defense that John was doing and he discussed how DOH works in 1 of the video.
After watching his video, it got me really interested to look at how it works, and since I’m having some break from work, I decided to spend more time looking at DOH in detail.
I’m learning how DOH works, so let me know if I’m wrong in any of my understanding or missed out on something important. :)
DNS over HTTPS (DOH)
DOH has first introduced about 2 years ago which is to provide security and privacy for internet users. The typical DNS query is not encrypted and anyone in the network can ‘see’ the DNS query of the sites that the users want to visit.
By using DOH, DNS query/response uses TLS to perform DNS resolution which provides the same kind of protection as the user is browsing to an HTTPS site. However, because of this, if an organization is implementing security controls on their DNS service (Eg: blackhole malicious domain on DNS service), it will no longer work as it is no longer required to use the DNS service that the organization runs (Beside the initial bootstrap DNS request).
To make things more interesting, there is another competing DNS encryption standard — DNS over TLS, which is not going to be discussed in this post.
The RFC…🥱
The RFC for DOH is RFC8484. I’m going to list down some of the points that I think are useful.
- DOH can be using HTTP Get or Post method
- When using Get method, DNS query is part of the URI
- When using Post method, DNS query is included as the message body of the HTTP request
- HTTP header Accept — “application/dns-message” or “application/dns-json”
- HTTP header content-type — “application/dns-message”
- HTTP/2 is recommended to use for DOH
- Before performing DNS resolution, the client must establish that the HTTP request URI can be used for the DOH query
- The maximum size for the DNS message is 65535 bytes
- Before DOH request can be made by an endpoint, it needs to have a way to resolve the DOH server (bootstrap), so it knows where to send the DOH request to
Response Code
One important thing to note, a 2xx status code response does not mean the DNS query returns a valid answer, it just meant that the query was successful but the DNS response could be eg: NXDOMAIN, SERVFAIL.
- 200: Ok
- 413: Payload too large
- 415: Unsupported Media Type
There are other response code, which you could refer to in the google doh documentation.
PCAP or it didn't happen
Setup
- Firefox 84.0
- Windows 10
- Wireshark 3.4.1
I have setup Firefox and Wireshark on a Windows 10 VM to perform the test. You could follow along with the video by John if you want to learn how to set it up. Different browsers may implement DOH slightly differently, so you might see things differently in Firefox/Chrome/Edge etc.
When Firefox was launched, there were multiple DNS queries made before DOH queries (I have added the SSL key in Wireshark that’s why DOH shows up). The plain DNS queries are likely due to the Firefox homepage as well as the bootstrap lookup for DOH server.
Without adding SSL key, the traffic showed up as TLS, which is not possible to identify that the traffic is DNS query without SSL interception.
When traffic is decrypted, you could see that the first packet was made to the DOH server with POST to /dns-query on HTTP2 protocol. The request was made to check if the DNS server accepts DOH query.
Both the Accept and content-type are “application/dns-message” which is required for DOH query.
The top is the query made over DOH and the bottom is the typical DNS query. Both look pretty much similar with query name, type etc.
Like the DNS request, the DNS response for DOH and DNS are pretty similar.
Without browser
Now, let’s try to perform DOH query using python instead of a browser. Instead of POST, I’m going to use GET to perform DOH request.
When using GET to perform the request, the query “wired.com”and type “A” is part of the GET URI. Without decrypting the packet, it just shown up as TLS connection.
In the response packet, the DNS answer is return in JSON format
The above shows the request and response flow. The different DNS fields are returned in JSON format.
Detection… 😦
I think it’s hard to do detection just based on TLS connection. Johannes has provided some suggestions which I have not personally tried before (I probably should find something to try).
If you do SSL interception in your environment, then just looking at the HTTP headers will show if it is DOH or not.
Reference
https://support.mozilla.org/en-US/kb/firefox-dns-over-https