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

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.