09-10-2019 03:20 AM
I just came across this article by ISC:
Will Infoblox provide a way to do this for customers that don't have a DNS Firewall license? Seems like a big cost to buy a license just to disable DoH? Maybe Infoblox can add a "tick box" in the UI somewhere?
09-10-2019 11:14 AM - edited 09-10-2019 11:37 AM
Granted I've not been following this closely. But one could add use-application-dns.net as an auth zone with no A or AAAA apex records -- messy but does the trick (unless dnssec signed, and even then one could sign and add a TA for it).
09-10-2019 01:39 PM
According to this article by Martin Brinkmann, "Enterprise configurations are respected as well and DoH is disabled unless "explicitly enabled by enterprise configuration". Also, the feature can be disabled by setting the value of network.trr.mode to 5 in about:config.
And as Dave already pointed out, there is the "canary domain" of “use-application-dns.net”. And this Mozilla support article goes into more detail of additonal checks that are made at the beginning of each browser session before enabling the feature.
But "If a user has chosen to manually enable DoH, the signal from the network will be ignored and the user’s preference will be honored."
09-11-2019 01:38 AM
Not sure if the canary domain will work in this case, they are specifically looking for NXDOMAIN, but if you create a domain with no apex records, you still have an SOA, so I think you will get a NOERROR response instead.
I just tried it on my internal DNS here:
paul@ubuntu-dev-1:~$ dig use-application-dns.net. a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> use-application-dns.net. a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52599 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; AUTHORITY SECTION: use-application-dns.net. 3600 IN SOA ns1.cn.corp. hostmaster.cn.corp. 587205058 1800 600 2592000 3600 ;; Query time: 0 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Wed Sep 11 09:36:08 BST 2019 ;; MSG SIZE rcvd: 139
09-11-2019 08:20 AM
And arriving in Chrome v78: https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html.
Unlike Firefox hardcoding Cloudflare, Google will initially support six providers. And will only use DoH if one or more of those is already configured in the OS - https://www.chromium.org/developers/dns-over-https
09-11-2019 10:00 AM
Well, that's a slightly better approach I suppose, but could still result in guest wifi networks that use 126.96.36.199 having DoH inadvertantly enabled.
I'm struggling to understand how you manage the exceptions if you need local resolution, e.g. for public FQDNs defined internally on internal IPs. It's a hack I see quite common, but with DoH those queries will be resolved externally, which is going to break stuff.
Feels like DoH just needs to be turned off to prevent all the aggro it's going to cause. How easy is it to deploy Firefox policies across the network, does they support Group Policy? What about Linux clients? What about all the other browsers? Gaaaah!.....
10-02-2019 09:14 AM
Sorry, I've been away from this for a while...
Firefox will attempt to resolve this domain using the DNS server(s) configured in the operating system of the device, and examine the result. The result will be considered negative if:
- A response code other than NOERROR is returned, such as NXDOMAIN (non-existent domain) or SERVFAIL
- A NOERROR response code is returned, but contains neither A nor AAAA records
The result will be considered positive if:
- The query completes with NOERROR and contains A or AAAA records (or both)"
Based on the article above noerror nodata is considered the same as a specific NXDOMAIN response, so the zone with no apex records would still work for this.
10-07-2019 08:13 AM - edited 10-07-2019 08:21 AM
11-27-2019 04:25 AM
If you want to catch more than just Mozilla as it's not the only thing out there doing, I'd suggest a local RPZ that blocks the names of all the weel known DoH services. We've observed quite a variety of mobile applicatiosn that use DoH without any use input or options at all.
I've got a manually maintained RPZ of all the DoH providers I've been able to discover,
But you probably want to ask your RPZ/firewall vendors to add DoH as a blocking category.
Of course if the only DoH usage you're worried about is Mozzila then just the canary domain will work fine.