How do I check if my operating system routes DNS over DoH or DoT system-wide?
Executive summary
A reliable check for whether an operating system routes DNS system‑wide over DNS‑over‑HTTPS (DoH) or DNS‑over‑TLS (DoT) combines three methods: inspect OS network/DNS settings for DoH/DoT entries, observe encrypted DNS traffic and ports on the wire with a packet capture, and run explicit DoH/DoT queries from the host with command‑line tools — each method has blind spots and must be combined to be sure [1] [2] [3].
1. Check native OS settings and the network interface first
Start by examining the OS-level network settings for a DNS encryption toggle or known DoH/DoT server addresses: Windows Server 2022 exposes a DNS client DoH configuration in the interface DNS settings where the Preferred/Alternate DNS can be set only if those addresses are on the list of known DoH servers [1], and many OSes or distribution packages provide explicit fields for a DoH URL or a DoT server address [4].
2. Use vendor‑supplied “are you using DoH?” test pages and browser indicators
Browsers and public resolvers provide diagnostics — for example Cloudflare’s guidance directs visiting their 1.1.1.1 help page to check a “Using DNS over HTTPS (DoH)” indicator after enabling secure DNS in the browser [5], and Firefox/Chrome may show whether application‑level DoH is active for that browser [4]. These checks confirm browser‑level DoH but do not prove system‑wide routing when other processes or the OS resolver could be using a different path [5] [6].
3. Capture traffic and watch ports to distinguish DoT from DoH
A packet capture is the most direct way to see whether DNS traffic leaves as encrypted HTTPS vs. TLS on the DoT port: DoT uses a dedicated TLS port 853 while DoH runs over standard HTTPS port 443 and therefore looks like regular HTTPS in captures [2] [4]. If TLS packets destined for port 853 with DNS‑like sessions are present, that indicates DoT; if DNS queries are embedded in HTTPS sessions on port 443, that indicates DoH — but remember that DoH blends with other HTTPS traffic and may be harder to single out [2] [4].
4. Run active tests from the host: DoH/DoT‑aware clients and DNS queries
Command‑line tools can test specific resolvers with DoH/DoT options: examples include using dig’s +https option to send a DoH query to cloudflare‑dns.com or using utilities like kdig/dog that support DoH/DoT, which proves the host can talk DoH/DoT to a chosen resolver [3]. Running queries to resolver test names (services that reply differently via DoH vs DoT) can also reveal how the resolver was reached, but such tests only prove the client that ran the test used the encrypted tunnel, not that every system process does [2] [3].
5. Watch for middle layers and blind spots: browsers, local resolvers and middleboxes
Encrypted DNS can be implemented at several layers: browsers often implement DoH independently of the OS resolver so browser tests can be misleading for system‑wide coverage [4] [6]. Conversely, local services like Pi‑Hole or cloudflared can accept plain UDP from clients and then forward encrypted DoH/DoT upstream, so traffic captures from the client may show cleartext to the local resolver while only the resolver‑to‑upstream leg is encrypted [6]. Network appliances, VPNs, and router DNS settings can also intercept or override DNS, creating gaps that require checking each link in the chain [4].
6. Combine evidence and accept limits of observation
A conclusive determination requires corroboration: OS network settings that list DoH/DoT endpoints, packet captures showing TLS to port 853 (DoT) or HTTPS sessions carrying DoH on port 443, and active DoH/DoT client queries that succeed together form strong proof [1] [2] [3]. If any single method contradicts the others, inspect intermediaries — browser flags, local resolvers like cloudflared, VPNs, or router settings — because each layer can route DNS differently and public tests can only see what reaches the public resolver [6] [4].
7. Practical checklist and final caveat
In practice: inspect OS DNS settings for DoH/DoT entries (Windows Server provides explicit UI controls) [1], run a packet capture and look for TLS on port 853 or HTTPS on port 443 indicating DoT or DoH respectively [2] [4], and run a DoH/DoT query with dig +https or kdig to validate the path [3]; still, if the environment uses a local DNS proxy or a browser‑only implementation, those will create legitimate exceptions and cannot be resolved without checking those components directly [6].