Reply To: DNS Filtering Best Practices with DOH now

Forums › Service Issues › Networking, Routing, Technology › DNS Filtering Best Practices with DOH now › Reply To: DNS Filtering Best Practices with DOH now

b32fc45f9641
January 1, 2020 at 10:02 pm

I certainly share your grief. So long as you are blocking the “Proxy & VPN” category, you should be able to stop most of the DoH providers that I contributed in a separate post.

DNS-over-HTTPS (DoH) providers not classified as "Proxy & VPN" or similar

My understanding of how Firefox’s implementation of DoH works:

  1. FF looks at the DoH URL specified by the end user
  2. If the URL contains a domain name (Ex. mozilla.cloudflare-dns.com), and the setting “network.trr.mode”=2, FF sends a DNS query over port 53 to either:
    The DNS forwarder IP handed out by DHCP
    The DNS forwarder IP statically assigned by the user in the network settings on their device
  3. If the URL contains a domain name (Ex. mozilla.cloudflare-dns.com), and the setting “network.trr.mode”=3, FF grabs the IP from the setting “network.trr.bootstrapAddress” (effectively, a permanent cache)
  4. FireFox connects to the DoH server over HTTPS and verifies that the server’s HTTPS certificate is valid for the domain OR IP that was specified
  5. All subsequent DNS queries are forwarded to the DoH server privately over port 443 (HTTPS)

By blocking outbound traffic to port 53 (DNS), you should be able to stop FireFox from getting the IP of the DoH server if it doesn’t already have it. That last part presents the most problems:

  • Some DoH providers have already gone about creating HTTPS certificates that allow you to access the service via their IP addresses without any certificate errors. A great example of this is CloudFlare. Unless you configure your firewall to block all traffic to 1.1.1.1, users will be able to specify this IP in their FireFox settings. Quad9 is another one. I haven’t seen any others just yet, but it is just a matter of time.
  • FireFox seems to cache the response back in step 2 above. This means that a mobile device could move to a network without CleanBrowsing enforced, cache the IP of the DoH provider in FF, and after the device moves back to your network, FF may be able to use the cached IP to send DoH queries without issue (bypassing the filter). I haven’t tested this, but it might work if FF expires the cache per the record’s TTL and the TTL happens to be rather lengthy.
  • The “network.trr.bootstrapAddress” setting allows end users to bypass the need to send any un-encrypted DNS traffic and effectively bypass all DNS filtering provided by CleanBrowsing

The only effective means to block DoH without sacrificing privacy seems to be IP blacklisting. HTTPS filtering can help, but it will reduce user privacy and is hard to pull off in a home environment. Sadly, the CleanBrowsing app doesn’t have any IP blacklist capability to deal with this issue, so mobile users will get past the DNS filter unless you create your own VPN and “tether” them to your firewall using MDM policies.

Some other ports you may want to block are 853 (DNS over TLS), 5053 (DNS over HTTPS Alternate used by CloudFlare), and 784 (DNS over QUIC).