12 Client behavior and diagnostics

12.1 A query is more than sending bytes

A DNS client creates a random transaction ID, encodes one question, sends it to an intended server, receives a response, and validates at least:

• source endpoint where the transport permits;
• transaction ID;
• QR and response shape;
• matching question;
• declared section lengths and names;
• truncation, with TCP retry when needed.

src/client.rs reads DNSCACHEIP or /etc/resolv.conf, supports IPv4 and IPv6 socket syntax, gets IDs from the operating system, applies UDP timeouts, rejects mismatched responses, and retries truncated UDP replies over TCP. The small command binaries format results for different use cases, while dnsq allows an explicit server and dnsqr uses recursive configuration.

dnstrace is conceptually different from a recursive lookup: it exposes the delegation path and intermediate authority so an operator can see where the chain stops. Good diagnosis asks four separate questions:

1. What did the stub send?
2. What did the recursive resolver cache or validate?
3. What delegation did the parent publish?
4. What does the authoritative server say directly?

Testing only the final application collapses all four layers and encourages guessing.

12.2 Practical checks

When a name fails, inspect type, server, flags, and authority section rather than asking only whether an address appeared.

dnsq A www.example.com 192.0.2.53
dnsq AAAA www.example.com 192.0.2.53
dnsq SOA example.com 192.0.2.53
dnstrace A www.example.com

Compare UDP and TCP when answers are large. Query the parent-side NS records and the child authority separately. An NXDOMAIN with an SOA is different from a timeout, SERVFAIL, or REFUSED, and each points to a different layer.