2026-06-02

DNS Timeout, NXDOMAIN, and SERVFAIL in PCAP: How to Tell Slow DNS from a Slow Server

How to diagnose DNS timeouts, NXDOMAIN, SERVFAIL, repeated queries, and slow application startup using packet capture evidence.

Many "slow application" cases are really DNS cases. A user clicks a button, the app waits several seconds, and the first blame goes to the server. A packet capture may show that no TCP connection was even attempted until DNS resolution finished or failed.

DNS evidence is compact, but it is easy to misread. NXDOMAIN, SERVFAIL, and timeout are different outcomes. Treating them as one generic "DNS error" leads to the wrong owner.

Timeout Means No Usable Answer Arrived

A DNS timeout usually appears as repeated queries with no useful response. The client may retry the same name, query multiple resolvers, or fall back from IPv6 to IPv4. The key sign is time passing before the application can move on.

Inspect:

query name
query type: A, AAAA, CNAME, SRV, etc.
resolver IP
retry interval
whether any response arrived
time until TCP or TLS connection begins
whether multiple resolvers behave differently

If there are several seconds of DNS retries before a connection attempt, the server is not slow yet. The client has not reached it.

NXDOMAIN Is a Valid Negative Answer

NXDOMAIN means the name does not exist. That may be an application configuration issue, typo, stale domain, split-horizon DNS issue, or expected lookup for optional behavior. It is not the same as no response.

Useful questions:

which name returned NXDOMAIN?
did the application try another name?
was this internal DNS or public DNS?
did search suffix expansion create unexpected names?
did the negative answer arrive quickly?

A fast NXDOMAIN is often not a performance problem. It is a correctness problem.

SERVFAIL Points Toward Resolver or Authority Trouble

SERVFAIL means the resolver could not complete the answer. Causes can include DNSSEC validation failure, unreachable authoritative servers, resolver misconfiguration, or partial outage.

A PCAP near the client may show only the resolver's final SERVFAIL. A capture near the resolver may show upstream queries and where they fail. Capture point matters.

Why PCAP Surgery Cares

PCAP Surgery is not a DNS server. Its role is to help engineers isolate evidence inside packet captures, trim relevant windows, preserve timing, and prepare defensible handoff files. DNS cases often need small, focused extracts:

queries before the application connection
resolver responses
retry timing
related TCP/TLS connection after resolution
enough context to prove DNS was the delay

If a large PCAP contains a 10-second user-visible delay, extracting the DNS query window plus the first connection attempt can make the support case much easier to review.

What to Preserve in a DNS Troubleshooting Capture

Preserve:

timestamps
DNS transaction IDs
query and response pairs
response codes
resolver IPs
client IP
follow-up connection timing

Be careful when anonymizing. If query names are removed completely, the recipient may not know whether the failure was typo, internal domain, public domain, or search suffix behavior.

For search queries like "DNS timeout pcap," "NXDOMAIN vs SERVFAIL," or "slow DNS packet capture," the key is to prove whether the application waited on resolution before it ever reached the server.

DNS result matrix

Match query name, type, class, transaction ID, client port, resolver, and timing. Transaction IDs are reused; ID alone is not a unique key in a busy capture.

Outcome	Packet evidence	Primary next check
Timeout	Query/retries, no matching usable answer	Path, resolver logs, capture point
NXDOMAIN	Explicit RCODE for the queried name	Name/configuration and authoritative data
SERVFAIL	Explicit resolver processing failure	DNSSEC, delegation, upstream resolver logs
REFUSED	Resolver declines policy/service	ACL and resolver policy
NOERROR, no answers	NODATA for requested type	Record type/configuration
Truncated UDP	TC bit followed by TCP fallback	TCP reachability and client behavior

Do not call NOERROR with an empty answer NXDOMAIN. The name may exist while the requested type does not. Preserve authority records and CNAME chain where visible.

Build the application-startup timeline

Record first query, every retry/resolver change, final DNS outcome, and first SYN/QUIC packet. This directly separates DNS wait from server response time.

12:00:00.000 A query to resolver 1
12:00:02.000 retry, no response observed
12:00:04.000 query to resolver 2
12:00:04.020 NOERROR answer
12:00:04.024 TCP SYN to returned address

The user’s four-second delay occurred before TCP. The application server cannot account for that interval, though resolver configuration, network path, or client retry policy can.

How do search suffixes create delay?

An unqualified name can produce a sequence such as service.site.example, service.corp.example, then service. Record each expanded QNAME and result. A fast NXDOMAIN for several suffixes can still add noticeable delay without packet loss.

How do A and AAAA queries interact?

Clients may issue them in parallel or sequence and race IPv6/IPv4 connections. Record both types and subsequent address selection. An AAAA timeout may or may not block A depending on resolver and Happy Eyeballs implementation.

Can DNS caching hide the problem?

Yes. A warm cache can bypass recursion while a cold query fails. Record TTL, cache state where known, and test warm/cold paths separately. Negative answers also have caching semantics.

SERVFAIL investigation

At the client capture point, SERVFAIL proves the recursive resolver returned failure, not why. Collect resolver logs and, when authorized, capture its upstream queries. Common causes include DNSSEC validation, lame delegation, unreachable authoritative servers, timeout, or internal resource failure.

Resolver-side evidence	Lead
Repeated authoritative queries, no reply	Upstream/path/authority timeout
DNSSEC validation error	Chain/signature/time issue
Different resolver succeeds	Resolver/path/cache policy difference
All resolvers fail identically	Authoritative/configuration lead
SERVFAIL only for large responses	UDP fragmentation/TCP fallback/MTU

Clock drift can break DNSSEC validation near validity windows, so correlate time-sync status when logs indicate signature timing.

NXDOMAIN correctness checks

Compare exact spelling, trailing dot behavior, search domain, split-horizon view, VPN state, resolver address, and authoritative data. An internal name queried through a public resolver can return a correct public NXDOMAIN while the application configuration is wrong.

Do not “fix” NXDOMAIN by hardcoding an address without understanding TTL, failover, service discovery, and certificate hostname implications.

Encrypted DNS boundary

DoH and DoT move DNS inside TLS/HTTPS. A port-53 filter can be empty while the application resolves through an encrypted resolver. Identify known resolver connections, OS/browser policy, and endpoint logs. Without keys, the PCAP may establish connection timing but not QNAME or RCODE.

Regression and handoff

Test the same names/types against intended resolvers under controlled warm and cold cache conditions. Require expected RCODE/answer within target latency and verify the next connection starts promptly. Preserve one healthy comparable lookup.

Include client, resolver, QNAME/type, transaction IDs, retries, response codes, answer/TTL, UDP size, fragmentation, TCP fallback, resolver failover, first connection time, capture point, and whether encrypted DNS may be used.

Create a focused artifact from the first lookup through the connection attempt. Use capture scope help, the DNS retransmission guide, and the privacy review because query names can expose customers, internal hosts, and behavior.

Direct answer: NXDOMAIN versus SERVFAIL

NXDOMAIN says the queried name does not exist in that DNS view. SERVFAIL says the resolver could not complete an answer. Timeout means no usable matching response arrived before the client gave up. They require different evidence and owners.

Worked ownership examples

Fast NXDOMAIN before any connection

The client queries api.internal.example through a public resolver and receives NXDOMAIN in 18 ms. No TCP SYN follows. The network is responsive; the likely issue is resolver selection, VPN/split-DNS state, or an incorrect name. Give the application/endpoint team exact QNAME and resolver, and the DNS team the intended view.

Repeated timeout then successful fallback

The client sends A/AAAA queries to resolver 1 at T0 and T0+2 s with no visible reply, then resolver 2 answers at T0+4.1 s. TCP begins immediately. The four-second startup delay belongs to resolver/path/retry policy before the server connection. Compare both sides of resolver 1 before locating packet loss.

Immediate SERVFAIL

The resolver answers SERVFAIL in 30 ms. Client reachability to the resolver works. Resolver logs are required for DNSSEC, delegation, upstream timeout, or policy detail. Repeating client captures will not expose hidden recursive processing.

Response-size and transport QA

Large DNSSEC or multi-record answers may fragment over UDP or set TC for TCP fallback. Preserve EDNS advertised size, response length, IP fragmentation, TC bit, and TCP connection. A client that never falls back can report timeout even though the resolver behaved correctly.

Symptom	Packet question
Small names work, DNSSEC names fail	Are large UDP fragments or TCP fallback missing?
UDP truncated, TCP SYN reset	Is port 53/TCP blocked?
Response leaves resolver, not client	Where is fragment/return traffic lost?
FORMERR after EDNS	Does resolver/middlebox mishandle options?

Does changing to a public resolver prove the internal resolver is broken?

No. Public and internal resolvers may serve different views, policies, DNSSEC behavior, and network paths. It is a comparison, not a universal fix. Avoid leaking internal names to unauthorized resolvers.

What should monitoring measure?

Measure RCODE rates by resolver and zone, latency distributions, retry/fallback counts, cache hit/miss where available, TCP fallback failures, and the time from first lookup to connection start. Alert separately for timeout, SERVFAIL, and NXDOMAIN spikes.

Final evidence statement template

“At the client capture point, queries for NAME/TYPE to RESOLVER at T0 and T1 received no response; resolver 2 returned NOERROR at T2, and TCP started 4 ms later. The capture establishes a DNS-stage delay but cannot distinguish query loss, response loss, or resolver non-response at resolver 1.”

This phrasing gives the next owner a testable boundary without calling the application server slow or claiming a packet disappeared on a specific link.

QA before closing the DNS case

Verify the intended FQDN and record type from application configuration, the resolver actually selected by the client, and the DNS view expected on that network. Repeat with a cold cache and record every response code. Confirm that the returned address leads to the expected endpoint and certificate identity.

If the fix changes retry order or resolver fallback, test partial failure: preferred resolver slow, secondary healthy; IPv6 answer absent, IPv4 healthy; UDP truncated, TCP available; VPN disconnect/reconnect. The application must fail within a bounded time or recover without producing a much longer hidden wait.

Keep negative tests authorized and rate-limited. Repeatedly querying nonexistent production names can pollute monitoring and caches. A synthetic zone under team control is better for regression.

The acceptance condition includes user timing: DNS reaches the expected answer/error within target latency, the connection begins promptly when an address is available, and logs identify the same bounded outcome shown in the capture.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: