How to handle DNS over HTTPS
About this Document
In this document, we explain how DNS over HTTPS is handled by AXS Guard and what you can do to prevent applications from bypassing DNS security and monitoring.
About DNS over HTTPS
When you type a web address or domain name into your address bar, e.g.
www.mozilla.org, your browser sends a request over the Internet to
look up the IP address for that website, a.k.a. DNS resolution.
Traditionally, this request is sent to servers over an unencrypted, plaintext connection, which means that third parties, such as system administrators can see which websites are being accessed.
DNS over HTTPS (DoH) works differently. It uses an encrypted connection to resolve the web address, which prevents third parties, such as system administrators, from seeing which websites are being accessed.
DNS over TLS (DoT) is frequently mentioned together with DNS over HTTPS (DoH). Although their goals are the same, i.e. the encryption of DNS requests, their methods differ. As specified in RFC 7858, DNS over TLS uses dedicated ports (TCP & UDP 853). Simply block these ports in the AXS Guard firewall if you wish to block DoT traffic.
Issues with DNS over HTTPS
DNS over HTTPS is problematic for the analysis and monitoring of DNS traffic for cyber security purposes. DoH can be used to bypass company content-control software and DNS policies, as it uses encryption.
Some users and organizations heavily rely on DNS to block malware, enable parental controls or to control access to certain websites.
When enabled, DoH will bypass the local DNS resolver of the client and users will be able to access potentially forbidden and harmful content.
Handling various Client Implementations on AXS Guard
When DNS over HTTPS is enabled in Firefox, the browser overwrites all local DNS settings and will always use DNS over HTTPS.
Firefox implemented a mechanism to automatically disable or enable DNS over HTTPS based on a canary domain. This canary domain is used by the heuristics check in Firefox, which is only executed whenever the browser is started and when the user has not already explicitly enabled or disabled DNS over HTTPS. Note that both conditions must be fulfilled.
The Firefox internal heuristics check will attempt to resolve the canary
use-application-dns.net. If the DNS query returns a
without A or AAAA records, a
message, it means that DNS over HTTPS has been successfully disabled.
The canary domain is added by default to the internal DNS repository of the AXS Guard appliance:
# Replace "192.168.250.254" with the actual LAN IP address of your AXS Guard appliance. $ dig use-application-dns.net @192.168.250.254 ; <<>> DiG 9.18.14 <<>> use-application-dns.net @192.168.250.254 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3916 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 6fefd6f20049c36301000000645a471cead46b56c8f0fad0 (good) ;; QUESTION SECTION: ;use-application-dns.net. IN A ;; AUTHORITY SECTION: use-application-dns.net. 1730 IN SOA ns.use-application-dns.net. hostmaster.use-application-dns.net. 1683620498 16384 2048 1048576 2560 ;; Query time: 0 msec ;; SERVER: 192.168.250.254#53(192.168.250.254) (UDP) ;; WHEN: Tue May 09 15:14
NOERROR status in the header section of the response indicates that the query was successful and there were no errors.
The mechanism described above will only work for users who didn’t already explicitly enable or disable the DoH option in their Firefox browser.
There is a way to restore the default browser behavior by changing some Firefox configuration options:
about:configin the browser’s address bar, press enter and accept the warning.
Set the following options to
Close and restart Firefox.
When DNS over HTTPS is enabled in Google Chrome, it will still use the configured DNS server. However, Chrome will default to DNS over HTTPS if the configured DNS server supports it.
This implementation prevents Google Chrome from hijacking the operating system’s DNS settings, which is a more sensible approach for enterprise environments.
Currently, Chrome’s DNS over HTTPS implementation works as follows:
A user types in a website into the browser’s address bar.
Chrome looks at the operating system’s DNS server.
Chrome checks if this DNS server appears on a whitelist of approved DNS-over-HTTPS-capable DNS servers.
If yes, Chrome sends a DoH (encrypted DNS query) to the DNS server.
If not, Chrome will send a regular DNS query to the same server.
Chrome currently supports the following DoH providers: CleanBrowsing, Cloudflare, Comcast, DNS.SB, Google, OpenDNS and Quad9.
No configuration changes are needed on AXS Guard to disable DNS over HTTPS when Google Chrome browsers are used.
Microsoft’s implementation is the same as Google Chrome. No configuration changes are needed on AXS Guard.
DNS over HTTPS is disabled by default in Opera; no configuration changes are required on AXS Guard. If enabled, Opera will default to DNS over HTTPS and use the Cloudflare DNS resolvers (184.108.40.206).
Starting with Windows Server 2022, the DNS client supports DNS over HTTPS. When DoH is enabled, DNS queries between the Windows server’s DNS client and the DNS server pass across a secure HTTPS connection rather than in plain text.
By passing DNS queries across an encrypted connection, users will be able to access potentially forbidden or harmful content and bypass DNS monitoring and security measures.
The central administration of DoH can be managed with a group policy. For individual clients, a corresponding option is available in the network settings app.
Blacklisting IP addresses of Public DoH Servers
Blocking the IP addresses of public DNS over HTTPS or DoH servers can be a useful security measure to prevent unauthorized or malicious use of DoH.
Public DoH servers are often used as an alternative to traditional DNS servers to encrypt DNS traffic and protect user privacy. However, they can also be used to bypass content filtering or monitoring, or to exfiltrate data from a network.
By blacklisting the IP addresses of known public DoH servers with an AXS Guard firewall block list, organizations can prevent this traffic from leaving their network and enforce their security policies. This approach can complement other security measures such as web filtering or DNS monitoring.
DoH servers use a large number of IP addresses that may change over time, so it's important to maintain an accurate and up-to-date list of all IP addresses and update your firewall configuration accordingly.