Article 1: Understanding Encrypted DNS and What a DNS Leak Actually Means

The foundations: DNS, plaintext resolution, DoT, DoH and the difference between encryption and privacy.

What DNS Does

The Domain Name System translates names such as www.example.com into network addresses. A device normally needs DNS before it can establish many application connections.

Traditional DNS commonly uses UDP port 53 and can also use TCP port 53. Those packets can expose queried names to devices that can observe the traffic path.

What Makes DNS Encrypted?

DNS-over-TLS, usually called DoT, carries DNS through a TLS connection commonly associated with TCP port 853. DNS-over-HTTPS, or DoH, carries DNS messages inside HTTPS, commonly using TCP 443 or HTTP/3 over UDP 443.

What Is a DNS Leak?

A DNS leak generally means DNS resolution is happening outside the resolver, tunnel or policy boundary that the administrator intended to control. For example, a device might be expected to use the network's resolver but independently contact an external resolver.

Encryption alone does not tell you whether the resolver is authorised. A DoH connection can be encrypted and still bypass a network DNS policy.

What the TAP Contributes

• Visibility into plaintext DNS packets, if they cross the monitored link.
• Visibility into encrypted connection endpoints and ports.
• Packet timing and connection frequency.
• Evidence that a client is contacting an unexpected resolver or service.
• A packet-level record that can be correlated with endpoint logs.

Article 2: Building a Safe Network TAP and Wireshark Monitoring Point

How to place the TAP, connect the monitoring computer and capture traffic without becoming part of the data path.

Recommended Architecture

Why Use a TAP?

A passive Ethernet TAP creates a monitoring copy of traffic while the normal network connection continues through the inline ports. The capture workstation connects to the TAP's monitor output rather than becoming a router or bridge.

Physical Connections

1. Connect the upstream network device to the TAP input.
2. Connect the downstream router or firewall to the TAP output.
3. Connect the TAP monitor port to the capture PC.
4. Give the capture interface only the configuration needed for monitoring.
5. Start Wireshark and select the dedicated capture interface.

Start a Wireshark Capture

Open Wireshark, select the Ethernet interface connected to the TAP monitor port and begin a capture. Generate test traffic from a device you control so the packet trace has a known starting point.

Useful first filters include:

Capture Scope

For a clean lab, capture only the traffic required for the test and avoid storing unnecessary personal or sensitive traffic. Packet captures can contain metadata and, where protocols are unencrypted, application content.

Article 3: Finding Plaintext DNS Leaks with Wireshark

A practical packet-analysis workflow for discovering clients that still send DNS outside the expected resolver path.

Step 1: Find DNS Packets

Use the Wireshark display filter dns. This limits the displayed packets to traffic identified as DNS.

Step 2: Look for UDP or TCP Port 53

Traditional DNS is commonly associated with port 53. The following filter makes the transport condition explicit:

Step 3: Identify the Client

Inspect the source address of each DNS request. Compare it with your known device inventory or DHCP leases. Then inspect the destination address to determine which resolver received the request.

Step 4: Inspect a Request

Select a DNS packet and expand the DNS section in the packet details pane. In plaintext DNS, fields such as the queried name, query type and response information may be visible.

Step 5: Establish Whether It Is a Leak

Do not label every external DNS packet a leak automatically. First define the intended policy. A public resolver may be intentionally configured. A VPN client may also have its own resolver requirements.

Useful Investigation Filters

• dns — show DNS protocol traffic.
• dns.flags.response == 0 — focus on DNS queries.
• dns.flags.response == 1 — focus on DNS responses.
• ip.addr == 192.168.1.20 && dns — examine one client.
• ip.dst == 8.8.8.8 && dns — examine DNS sent to a specific destination.

Article 4: Identifying DNS-over-TLS and DNS-over-HTTPS Traffic

How to recognise encrypted DNS without claiming that Wireshark can magically decrypt it.

DNS-over-TLS

DoT commonly uses TCP port 853 and establishes a TLS session before DNS messages are exchanged. A TAP can therefore show the client-to-server connection and TLS handshake metadata, but the DNS query itself is normally encrypted.

DNS-over-HTTPS

DoH normally uses HTTPS and therefore blends DNS activity into ordinary web-style encrypted traffic. A simple port filter may show TCP 443 connections, but many other applications also use TCP 443.

Why Port 443 Is Not Proof of DoH

A connection to port 443 is not automatically DNS-over-HTTPS. It could be a website, software update, API call, telemetry service or many other HTTPS applications.

For a defensible investigation, combine packet metadata with endpoint configuration, known resolver addresses, browser settings and, where available, resolver-side logs.

What a TAP Can Still Reveal

• Client and destination IP addresses.
• Transport protocol and port.
• Connection start and end timing.
• Packet sizes and direction.
• TLS handshake characteristics where visible.
• Repeated connections to a known DNS provider endpoint.

What It Normally Cannot Reveal

• The plaintext DNS question inside DoT.
• The plaintext DNS question inside DoH.
• HTTPS application content protected by TLS.
• Passwords, cookies or private messages protected by encryption.

Article 5: Understanding DoH, HTTP/3 and QUIC Visibility

Why modern encrypted DNS can look very different from traditional DNS traffic.

From TCP 443 to UDP 443

Modern applications can use HTTP/3, which operates over QUIC. QUIC normally uses UDP, commonly including UDP port 443. This means an encrypted DNS service can appear as UDP traffic rather than the familiar TCP-based HTTPS connection.

Why This Matters for Leak Testing

A monitoring design that only searches for UDP/TCP 53 can miss encrypted DNS completely. The absence of plaintext DNS packets does not prove that a device is using the resolver you intended.

For example, a client may send no port-53 DNS traffic because the browser or operating system is using an encrypted resolver over HTTPS or HTTP/3.

Build a Protocol Inventory

Do Not Over-Interpret IP Addresses

An IP address can host multiple services or domains, and service providers can change infrastructure. Use current endpoint documentation, controlled test conditions and corroborating evidence rather than assuming that an IP alone identifies a specific DNS query.

Controlled Test

1. Start a TAP capture.
2. Record the client address under test.
3. Generate a small, known amount of DNS activity.
4. Stop unrelated applications where possible.
5. Compare port 53, 853, TCP 443 and UDP 443 observations.
6. Compare the capture with the endpoint's configured DNS settings.

Article 6: Investigating DNS Bypass, Resolver Mismatch and Policy Leaks

Turning packet observations into a structured investigation without confusing encryption with compliance.

Define the Expected Policy First

Before opening Wireshark, document the intended DNS architecture. For example, clients may be expected to use a local resolver, which then forwards requests to approved upstream services.

Capture and Compare

Use the TAP to observe the boundary where the policy should apply. Then compare the observed destination addresses and protocols with the documented architecture.

Example Investigation Matrix

Wireshark Correlation Filters

Separate Evidence from Assumptions

A good incident or troubleshooting report should state exactly what the capture demonstrates. For example: “Host 192.168.1.20 established repeated encrypted sessions to destination X during the test.” If you infer that X is a DNS provider, document the source used for that attribution.

Article 7: Building a Repeatable Encrypted DNS Leak Testing Lab

A complete test methodology for homelabs, training environments and authorised network troubleshooting.

Lab Components

• Router or firewall under your control.
• Managed switch where appropriate.
• Passive Ethernet Network TAP.
• Capture PC running Wireshark.
• One or more test clients.
• A documented DNS policy.
• Optional local resolver for controlled experiments.

Test A: Plain DNS Baseline

Configure a controlled test client to use a known DNS server. Start the TAP capture and perform several predictable lookups. Filter on dns and verify whether the expected DNS requests appear at the monitored point.

Test B: DoT

Configure the authorised test client to use a DoT resolver. Capture the traffic and filter for tcp.port == 853. You should expect to see an encrypted session rather than readable DNS questions.

Test C: DoH

Enable an authorised DoH configuration on the test client. Capture traffic while generating DNS lookups. Search for relevant encrypted HTTPS connections and correlate them with the client configuration. Do not assume every TCP 443 connection is DoH.

Test D: HTTP/3 and QUIC

Where the client and service support HTTP/3, examine udp.port == 443 and quic. This demonstrates why DNS monitoring based only on port 53 is incomplete.

Test E: Policy Enforcement

Apply your network's intended DNS controls, then repeat the tests. The purpose is to compare the observed traffic against the policy rather than to collect more traffic than necessary.

Example Test Record

How to Report the Result

A professional report should include the capture location, client address, test time, protocol observed, destination information, Wireshark filters used and the evidence supporting the conclusion.

Avoid reporting encrypted traffic as though its payload were visible. If the payload is encrypted, explicitly say so and describe the metadata that was actually observed.