How can I verify my search engine is using DoH or DoT on my device?
Executive summary
You can check whether your device uses DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) by inspecting browser or OS resolver settings, observing ports and endpoints in traffic or router logs, or using client tools that query specific DoH/DoT servers; DoH typically uses HTTPS on port 443 and DoT uses TLS on port 853 [1] [2]. Vendor docs and tests can confirm a client’s configured resolver (e.g., Firefox shows DoH provider; routers list DoH/DoT servers and offer verification commands) but it is impossible to enumerate or detect every DoH endpoint with certainty [3] [2] [4].
1. Look at the obvious: browser and OS settings
Modern browsers and some OSes let you pick an encrypted DNS provider and will display the selection: Firefox exposes a DoH setting that points to a named resolver (Cloudflare, NextDNS, etc.), and Cloudflare documents that Firefox DNS queries go to Cloudflare or NextDNS when DoH is enabled [2] [5]. Checking those client settings is the fastest first step because the application itself declares whether it will use DoH rather than the system resolver [2] [5].
2. Check your router or gateway for configured DoH/DoT servers
Many consumer routers now support DoH/DoT and show configured upstream encrypted resolvers in the web UI; TP‑Link’s support pages and Keenetic’s docs describe lists of DoH/DoT servers you can select and CLI commands to verify availability [3] [6]. If your router is set to “DNS Privacy = DoT/DoH” or provides a “DETECT DNS SERVER”/availability check, that’s evidence downstream clients may be served encrypted DNS by the gateway [3] [6].
3. Observe network traffic: ports and patterns reveal DoT vs DoH
Network visibility is useful: DoT normally uses a dedicated TLS port while DoH looks like ordinary HTTPS on port 443, so packet captures or firewall logs showing outbound connections to port 853 strongly indicate DoT; connections to port 443 to known DoH endpoints suggest DoH — but DoH is harder to differentiate from ordinary web traffic because it uses the same port and protocol as HTTPS [1] [2]. Security teams cite that DoH “camouflages” DNS inside HTTPS, making blanket detection or blocking more difficult [2] [1].
4. Use command-line or specialty tools to query specific encrypted DNS servers
Tools such as dnscrypt-proxy, kdig (Knot DNS), or DoH/DoT-capable clients let you make explicit DoH or DoT queries to a resolver and observe whether you get a valid encrypted response; community Q&A notes kdig supports DoT and DoH and dnscrypt-proxy can act as a local forwarder, useful for testing your path [7] [8]. These tests prove that a given encrypted resolver responds, but they don’t prove all client traffic on the device is using that service unless you test from the same client process and context [7] [8].
5. Beware the limits: you cannot enumerate every DoH endpoint
Security analysts warn it is impossible to enumerate or detect every DoH URL with certainty because DoH traffic can blend into normal HTTPS and services can host resolvers on many domains; a blog analysing encrypted DNS emphasizes that detection is fundamentally limited and uses dns.google only as an illustration [4]. That means negative results (you don’t see DoH) aren’t definitive; absence from logs could be DoH traffic hidden on port 443 or routed through an intermediary resolver [4] [2].
6. Corporate and network controls change the story
Enterprises use firewalls and special rules to permit or block DoT and DoH; Palo Alto Networks notes properly configured firewalls can prohibit or control DoT and DoH traffic, and Cisco describes delivery and discovery mechanisms (DDR) that affect which encrypted transports devices will use [9] [10]. If you’re on a managed network, admins may force all DNS through a monitored gateway or block unknown DoH endpoints — checking with IT is a valid path because local policy can override client behavior [9] [10].
7. Practical checklist to verify on your device right now
- Inspect browser/OS secure‑DNS settings for an explicit DoH/DoT provider [2] [5].
- Check router/web-GUI for “DNS Privacy” options and run any provided availability checks [3] [6].
- Capture outbound traffic: look for connections to port 853 (DoT) or to known DoH endpoints on 443 [1] [2].
- Use a DoH/DoT client (kdig, dnscrypt-proxy) to query a resolver directly and confirm encrypted responses [7] [8].
- If on managed networks, consult network admins because firewalls and discovery records can steer or block encrypted DNS [9] [10].
Limitations and context: available sources do not mention a single universal test that proves "all DNS from device is encrypted" across every app; detection gaps exist because DoH can hide among HTTPS traffic and discovery mechanisms can change which transport a device chooses [4] [2] [1]. Use a combination of client settings, router checks, traffic observation, and direct queries to reach a high-confidence answer [3] [7] [8].