Disabling DNS over HTTPS at the network level for Firefox

Mozilla have recently announced default use of the divisive DNS-Over-HTTPS. The non-issue that is trying to be addressed with DoH is that DNS lookups are unencrypted.

What does this really mean? 

• Well if you're on a shared network, then other users can snoop the names of sites you're visiting (e.g. google.com, or something more private). 
• Your government could easily request your ISP to provide a list of sites you're visiting. 
• Your ISP could be being forced to block certain DNS requests. 
• Your ISP can also see what DNS queries you are requesting, and then redirect your traffic to their own name-servers to give you a faster response (and then start hijacking non-existent domains to direct you to a holding page of some sort).

DoH moves the DNS query to an encrypted tunnel to a pre-defined DNS resolver.  You'll just have to take the word of Mozilla that this unknown (Cloudfare as it happens) is not logging your requests, blocking anything it's legally required to, or abusing their position by redirecting traffic.

The only hole DoH genuinely seems to plug is the local snooping on a shared network.  But with browsers such as Opera coming with a VPN built-in, plus less reliance on public WiFi as 4G becomes prevalent - I find the need very unconvincing.

By forcing DoH on users, you're forcing the moving of trust from whatever the user currently has selected (or preselected by their ISP) to another organisation.  It doesn't even address the major issue with DNS, and that's man-in-the-middle attacks, or DNS poisoning.  These issues are addressed with DNSSEC, and already established protocol that authenticates responses from the top down.  To address all the points above, you can't rely on DoH, but instead you should look at running a DNS resolver on your local network (or computer) that will verify DNSSEC records.  A bit complicated?  Yes, but not a folly either.

Still, what harm can DoH do?

1. Should be slower (TLS handshake, followed by a HTTP request is heavier duty then a simple UDP packet)
2. Will use marginally more bandwidth/data-allowance
3. Will completely break all access to your local network resource

Point 3 is the one that is going to cause the most annoyance.  If your local network is running a DNS server to manage the names of devices (e.g. any corporate network, and many more advanced home-routers), then you won't be able to type in the name of your local resource into your browser and expect it to find it - because DoH bypasses your setup.

Network level override

Fortunately for us, Mozilla have thought about this and we only need to go through effort ourselves as administrators to ensure everything continues to work.  The simple way to override the change on all client types is to block their "Canary domain": use-application-dns.net, and force an NXDOMAIN response.

Simple enough, but how does one do this?

BIND

It's simple enough if you happen to use this fairly obscure feature... Response Policy Zones.

First off, you need a new zone file along these lines (called "blockedhosts"):

$TTL 4w
@                         IN SOA          localhost.       root.localhost. (1 4w 1d 4w 1m )
                          IN NS           localhost.
use-application-dns.net   IN CNAME        .

Note the hostname we're using here doesn't have a trailing dot.  We're using a placeholder zone name '@', and the domain has a single CNAME record that point to dot.

This is a magic record, it doesn't mean what you might think.  The magic is enabled in your /etc/named.conf

We need a zone definition:

zone "blockedhosts" in {
    type master;
    file "master/blockedhosts";
};

With the file name adjusted as appropriate.  And then the magic, either in the relevant view section, or global options:

response-policy { zone "blockedhosts"; };

Reload named to pick up the changes.  The Response Policy Zone system works by allowing you to re-write requests when being sent back to the client.  Using a dot as the response, means BIND will return our required NXDOMAIN response.

You can also use this approach to black-hole lots of horrible domains, such as malware or advertising domains.  And being a standard zone file, it should be possible to transfer copies of this to your secondary name servers in the usual manner.