DNS over HTTPS (DoH) like so many other emerging protocols in a “post privacy” world is an attempt to wrap more layers of abstraction (crypto) around basic internet applications and functions.

The premise behind DoH is this: Instead of using the standard DNS protocol, your DoH client (mostly commonly a web browser) reaches out to a DoH provider/server and both agree to send DNS-like queries and responses over standard HTTPS.

The problem is that DNS was never designed with security in mind. As with E-Mail some additions were later added to help smooth over some security edges.

Just because you can do something, it does not always mean that you should. DNS is a very foundational protocol; are you okay with your browser using a different DNS mechanism instead of the one built into your OS? Are you still able to access your internal applications? If you suspect DNS issues how are you going to troubleshoot?

How does this thing work?

Cloudflare and Google provide really good documentation on DoH and you can always read the RFC if you need help sleeping at night.

Essentially, you have a DoH client built into your web browser (or even some routers) that is responsible for brokering all of the requests and replies. This traffic is little snippets of JSON, with the MIME content type of application/dns-json.

To generate a sample request, you can use curl to query a DoH resolver like the one Cloudflare operates.

CURL DOH Query
Request/Response example based on Cloudflare’s documentation
DOH SNI
It’s not DNS, its regular ole HTTPs. See Server Name Indicator (SNI) field highlighted for TLS. This is useful to look at later.

As demonstrated, DoH has the potential to bypass any DNS filtering as the actual query is encrypted. The only thing that you can see is someone using Cloudflare DoH (Server Name Indicator, highlighted in screenshot above). Because DOH rides alongside HTTPS you can’t just block it.

I will circle back to the technical aspects, now we should talk about why some people don’t like DoH.

My problem with DoH

DoH does work and I have not seen an appreciable overhead or degradation in performance. However, its important to be honest about what DoH does and doesn’t do. Specifically, some of the false hope it can give users about security and privacy.

Being concerned with privacy/digital rights, some aspects of DoH are appealing to me. The use of a Separate HTTPs broker to send and receive DNS queries in little bits of encryption JSON is very clever. It even seems to be upsetting large ISPs such as Comcast and AT&T. The enemy of my enemy is my friend right? Not always..

I prefer simple, plain ole DNS. The reason is Trust.

  1. Trusting your DoH provider - In instances of malware, you may have no idea who that provider is. Yes, you would have to trust your upstream resolvers in normal DNS. However, your local resolver/gateway can override the answers to queries , cache the records, and keep logs.

  2. Going blind - The lack of visibility not only creates trust issues with your DoH provider (should they be compromised), but it also circumvents internet filtering policies for legitimate use cases such as home or work monitoring.

  3. (Not specific to DoH) - For large organizations (proxy/decryption), It can be trivial to view sensitive HTTP/HTTPs information.

Even without decryption you will still be able to see the Sever Name Indication (SNI) field mentioned above. You can loosely think of SNI as hostname, but for the purposes of certificate verification/TLS handshake. Take a look at the screenshot below. There is no DNS query, but why is a TLS connection being established with Hysler.net? Could it be user activity?

HTTPs SNI in the clear

In short, DoH can provide some privacy benefits as DNS information is no longer plain text en massé. However, these can be mitigated by HTTP headers and partially by SNI field for HTTPs traffic. Metadata analysis on the destination IP addresses, source/destination ports can also reveal a great deal about the traffic in question.

You have to trust providers such as Cloudflare to make sure they are sending you the right responses. Something you can have slightly more control over with a local resolver or technologies like DNSSEC or DNSCrypt.

Blocking DoH: Home Network and Small/Medium Business Edition

Blocking DoH in a large enterprise is straightforward with if you have a managed external DNS service such as Cisco Umbrella (viva la OpenDNS!), a web proxy, and some GPOs.

However, in a home or Small/Medium Business (SMB) setting you are going to find unmanaged devices with various levels of security controls. The only reliable control you are likely to have is the network. Here are some proactive steps you can take to defeat DoH.

  1. Upstream DNS provider
  2. Blocking DoH Providers (IP/DNS)
  3. Preventing circumvention of #1 and 2
  4. (Optional/Opportunistic) - Endpoint controls

Using an Upstream DNS provider that is filtering out DoH domains

Services like OpenDNS prosumer have an option to block “DoH provider”; if you block the “Proxy/Anonymization”; category or if you use their DNS servers that filter out adult content. I know Cloudflare has a similar offering, but I have not been able to see if it blocks DoH or not.

There is a caveat to this approach, if you make the appropriate DoH request via direct IP you can still get around the DNS level protections.

Blocking DoH Providers

You can also use public block lists to prevent communication with DoH servers via hostname or IP address. The public lists may not be current, but they contain a few dozen servers including many I had never heard of.

Even if your router does not allow for block lists you can always use firewall rules to block some of the most common resolvers (as a last resort).

I use the pfBlocker-ng package for pfSense to automatically grab the latest version of the following lists from this Github project.

https://github.com/bambenek/block-doh

  1. DoH Hosts
Bambenek DOH domains
  1. DoH IPv4 and IPv6 lists
Bambenek DOH IPs

Preventing circumvention of existing DNS

This one is pretty straight forward. Make sure your gateway/router is giving your clients the right internal DNS server and that your gateway/router is using the right external DNS servers to resolve/respond to queries (Example: Google being 8.8.8.8, OpenDNS being 208.67.222.222, etc.)

Now you can use the built in firewall for your gateway/router to block any outbound DNS traffic that is not going to Google, OpenDNS, etc. You may break something here, I have seen some IOT devices try and use Google DNS for example.

Optional/Opportunistic: Blocking at the endpoint

Note: Information current as of July 2020

Does your router not let you do any of the above? Is there some other constraint but you still want to block DoH? There is good news, you can still block DoH manually. This is a good approach for a small number of devices and/or children with devices that have parental controls.

These methods require setting some hidden flags and options within browsers:

The obvious problems with this approach are that the locations for these settings may change or get inadvertently flipped by software updates and/or bugs. Secondly, it appears that Firefox is more likely to honor the end user going into Settings GUI and explicitly enabling DoH instead of about:config or network telemetry (such as canary domain).

Google, seems to have a more nuanced approach detailed in its blog post. Google is not going to change your DNS provider by default. Mozilla will change your DNS provider to one of its partners in its “Trusted Recursive Resolver”; program.

I hope that this post has been helpful in understanding DNS over HTTPS. For those of you who like to tinker and really like to control your own home network, I hope that you found some practical advice.

For me this blog post was largely inspired by being an enterprise defender and how to think through mitigating command and control traffic/DNS queries using DOH. It is also a useful exercise to think through blocking DoH where it makes sense as a parent, sharpen your InfoSec skills, and/or maintaining visibility on your network.

What do you think? Is there something I missed or got wrong? Want to talk about security? Shoot me an e-mail or lets talk on Twitter.

Thanks for reading,

-Justin
justin@hysler.net
@difr_justin