Detect encrypted DNS bypass without mistaking HTTPS for proof

To detect encrypted DNS bypass, correlate three things: a fresh lookup from the client, traffic to a resolver outside your approved DNS path, and evidence that the client used that resolver. Missing Pi-hole queries or a connection on port 443 alone does not establish bypass.

Here, bypass means a client resolves names outside the DNS path you intended it to use. Encryption is not itself a policy violation: an approved encrypted resolver is still an approved resolver.

This workflow is for devices and networks you own or are authorized to inspect. It does not require intercepting credentials or decrypting other users’ sessions.

Know what the capture can establish

Candidate traffic	Wireshark display filter	What it tells you
Conventional DNS	udp.port == 53 or tcp.port == 53	Inspect decoded queries and their destination. An external destination may indicate plaintext bypass, not encrypted bypass.
DNS over TLS (DoT)	tcp.port == 853	A candidate DoT connection; inspect the TLS exchange and resolver identity.
DNS over QUIC (DoQ)	udp.port == 853	A candidate DoQ connection; inspect QUIC and available handshake information.
DNS over HTTPS (DoH)	tcp.port == 443 or udp.port == 443	HTTPS or HTTP/3 candidates—not a DNS-specific test.

DoT uses TCP port 853 by default, but explicitly configured alternative ports are permitted by RFC 7858. DoQ uses UDP port 853 by default and negotiates the ALPN token doq; it also permits agreed alternative ports, including 443 (RFC 9250). Ports are a starting point, not exhaustive detection.

DoH carries DNS queries inside HTTP exchanges protected by HTTPS (RFC 8484). Cloudflare documents both HTTP/2 and HTTP/3 multiplexing for its resolver, so multiple queries can share one connection. Do not count TLS connections as DNS queries. See its DoH API documentation.

1. Establish the intended path

Before opening Wireshark, record:

• The client’s current IPv4 and IPv6 addresses.
• Its effective system resolver settings, not just the DHCP configuration you expected it to accept.
• Browser or application secure-DNS settings, including the selected provider and current status.
• Any VPN, local DNS proxy or privacy relay that changes the path.
• Which resolvers are approved, including any approved encrypted upstream used by Pi-hole or another local resolver.

A local resolver forwarding queries over DoH is not evidence that a client bypassed it. Keep the client-to-resolver and resolver-to-upstream legs separate.

If the resolver logs are empty, first consider cached answers, an application using an existing connection or literal IP address, a different resolver configuration, or incomplete logging. Absence from one log is a reason to investigate, not a protocol identification.

2. Capture where the client’s traffic is visible

Capture on the client, a properly configured switch mirror, or an appropriate router interface. A capture on the Pi-hole host alone generally cannot reveal traffic that goes directly from another client to an external resolver. On switched Ethernet, promiscuous mode does not make unrelated unicast traffic appear; Wireshark’s capture setup guide explains the visibility constraint.

A router’s LAN-side capture can preserve client attribution before IPv4 NAT. But it may miss client-to-Pi-hole traffic switched locally on the same LAN, so pair it with resolver logs or a client capture. For Wi-Fi, use the wireless-client capture guide.

Start before the test action so you have a chance to capture the handshake. Include both address families and both traffic directions. Avoid a port-53-only capture filter: it excludes the traffic you are investigating.

Use the table’s expressions as display filters after capture, scoped to the target client. For example, this selects port-443 candidates for a synthetic dual-stack client:

(ip.addr == 192.0.2.10 or ipv6.addr == 2001:db8::10) and (tcp.port == 443 or udp.port == 443)

Use your client’s actual addresses, including any additional IPv6 addresses used during the test. The parentheses keep the port condition applied to both address families. Wireshark’s display-filter documentation covers address comparisons and combining expressions with and and or.

3. Identify candidate resolver connections

For each candidate, record its destination, transport, time interval and whether replies arrive. Check destination addresses against the suspected operator’s current documentation rather than relying on an old resolver list.

When Wireshark exposes the field, this display filter finds packets containing TLS Server Name Indication:

tls.handshake.extensions_server_name

Inspect the value in the packet details. Wireshark documents this field in its TLS filter reference. A resolver hostname strengthens identification of the destination service, but it does not show the DNS question or prove that resolution succeeded.

For QUIC, inspect available ALPN information. An offered doq token supports a DoQ hypothesis; an offer is not proof that negotiation or a query completed. h2 and h3 identify HTTP protocols, not DoH specifically.

Do not expect to search an ordinary encrypted capture for /dns-query or application/dns-message: those are inside the protected HTTP exchange. Packet size and timing can support correlation, but they cannot reliably distinguish DoH from ordinary HTTPS.

Encrypted Client Hello can protect the real SNI and ALPN list, leaving public outer values instead (RFC 9849). Missing or generic SNI therefore does not rule out encrypted DNS. For the broader visibility boundary, see what HTTPS hides in a packet capture.

4. Run a controlled lookup comparison

On a managed test client:

1. Verify logging first: send a separate fresh test lookup explicitly to the approved resolver and confirm that its log records the name and client. Check the time-zone or clock offset between logs and capture timestamps.
2. Start the capture and note the time.
3. Make the suspected application request a fresh hostname under a domain you control. Prepare distinct, resolvable test labels for each run to reduce cache ambiguity.
4. Check the approved resolver’s log for that exact name and interval.
5. Check client diagnostics for the selected resolver, transport and lookup result, where available.
6. Change only the suspected secure-DNS setting to the intended path, repeat with another fresh label, and compare. Restore the intended configuration afterward.

Test the application that exhibits the problem. A command-line DNS utility may use a different resolver path from the browser; the logging check is a control, not a substitute for the application test.

Firefox, for example, exposes DoH status and protection settings. Mozilla documents that Off uses the default resolver, while fallback behavior varies by protection level. Record the actual mode and status rather than assuming all failures fall back (Mozilla’s DoH settings guide). The default system resolver may itself use encryption.

The useful comparison is a repeatable change: external resolver activity accompanies the first lookup, while the second lookup appears at the approved resolver after changing the application setting. That supports the bypass hypothesis; per-query client diagnostics provide stronger confirmation than timing alone. A provider setting or general “Active” status is not per-query confirmation.

5. Report the finding at the right confidence

• Confirmed encrypted bypass: per-query client diagnostics identify the unapproved encrypted resolver that returned the test lookup’s result, correlated with the capture. That lookup used a path outside policy; do not infer that every lookup does.
• Probable encrypted bypass: fresh lookups repeatedly correlate with a known encrypted resolver, that activity disappears when the relevant setting changes, and the original lookups are absent from verified approved-resolver logs, but per-query endpoint evidence is unavailable.
• Attempted or blocked use: connection attempts or policy logs show a denied encrypted-resolver path. Do not describe a denied attempt as successful resolution.
• Inconclusive: only missing DNS logs, opaque HTTPS flows or incomplete capture coverage are available.

If enforcement follows, test it separately. Redirecting port 53 does not redirect DoH, DoT or DoQ into a plaintext resolver. Blocking a resolver can produce fallback, failure or another path; verify the outcome rather than assuming it. Prefer managed settings and an approved encrypted DNS service where supported.

Keep the finding scoped to the tested client, application, configuration and interval. Share a redacted summary of destinations, transports and outcomes—not raw third-party captures or sensitive query names.