DNS diagnosis becomes more reliable when every result records the exact name, type, server, response code, flags, TTL, and observation time. A default lookup, a direct authoritative query, and a DNSSEC-validating query answer different questions.
The examples below use IANA-reserved names and addresses. Replace uppercase
placeholders such as RESOLVER_IP and AUTH_SERVER with an approved public
resolver or a nameserver discovered from the delegation. These are read-only
queries, but public servers can rate-limit repeated traffic.
Start with the query tuple
Record these values before running a command:
- fully qualified query name, such as
www.example.com.; - class and record type, such as
IN A; - exact server or resolver queried;
- whether recursion was requested;
- whether DNSSEC data or validation was requested;
- network or DNS view, such as public, VPN, or internal; and
- observation time.
Current DNS terminology distinguishes a recursive resolver from an authoritative server because their answers have different evidence boundaries [2].
Observe one recursive resolver
Use a named resolver instead of leaving the observer implicit:
dig @RESOLVER_IP www.example.com A +comments +answer +authority
Record:
status, such asNOERROR,NXDOMAIN, orSERVFAIL;- flags, especially
rd,ra, andad; - answer, authority, and additional sections;
- remaining TTLs;
- the
SERVERline; and - query time and timestamp.
The ad flag reports that the responding resolver considers the answer
authenticated. Its absence does not by itself prove that data is bogus. Compare
the same tuple through another named resolver only when a second observer helps
scope the failure.
The DNS Lookup pathway provides named public-recursive observations without requiring a local command. It does not replace direct queries to authoritative servers.
Discover the delegation path
Use a trace to follow referrals from the root toward the requested name:
dig +trace example.com NS
The BIND dig documentation states that +trace performs iterative queries and
automatically disables recursion
[3]. Read the
output in stages:
- root response referring to the top-level domain;
- parent response referring to the child zone;
- glue or other address data included with referrals; and
- final authoritative response.
A trace is a path observed from the current network at that time. Retries, anycast routing, and unreachable address families can change which server instances answer.
Query an authoritative server directly
First discover the intended nameservers:
dig example.com NS +short
Then query each listed server with recursion disabled:
dig @AUTH_SERVER example.com SOA +norecurse +comments
dig @AUTH_SERVER www.example.com A +norecurse +comments
For a positive authoritative answer, expect the aa flag. Capture the server,
status, flags, complete RRset, and TTL. A synthetic shape looks like:
;; ->>HEADER<<- status: NOERROR
;; flags: qr aa
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. ...
;; SERVER: 192.0.2.53#53
The exact layout varies by dig version. RFC 1035 defines the DNS message
header, sections, response codes, and authoritative-answer flag
[1].
If one intended authority lacks aa, refuses the query, times out, or publishes
a different RRset, preserve the difference before changing anything.
Inspect parent DS and child DNSKEY separately
DNSSEC crosses a parent and child control plane. Query each side directly:
dig @PARENT_SERVER example.com DS +norecurse +dnssec +comments
dig @AUTH_SERVER example.com DNSKEY +norecurse +dnssec +comments
Do not compare only a shortened digest fragment. Record every DS field, the complete DNSKEY RRset, relevant signatures, TTLs, and all responding servers.
To request local validation with BIND’s validating lookup utility:
delv example.com A
delv needs usable trust anchors and cryptographic support. A local
configuration error is not evidence that the public zone is bogus. Preserve the
validation message and confirm the chain with another approved diagnostic path.
Compare UDP and TCP
When a response is truncated, large, or intermittently failing, repeat the same direct query over TCP:
dig @AUTH_SERVER example.com DNSKEY +norecurse +dnssec +tcp +comments
Compare status, flags, completeness, server identity, and time. A successful TCP response alongside failed UDP can support a transport, firewall, fragmentation, or path-MTU hypothesis; it does not identify the cause by itself.
Use Resolve-DnsName on Windows
PowerShell can query an explicit server with DNS-only behavior and recursion disabled:
Resolve-DnsName -Name example.com -Type SOA -Server AUTH_SERVER -DnsOnly -NoRecursion
For a recursive observation, omit -NoRecursion and name the approved resolver
with -Server. Microsoft documents -Server, -DnsOnly, -NoRecursion,
-DnssecOk, and -TcpOnly for this command
[4].
Windows and BIND tools format sections and flags differently. Preserve the raw output when escalating so another operator can interpret the same observation.
Use one evidence record
For every comparison, keep:
Name:
Class and type:
Server and role:
Recursion requested:
DNSSEC request or validation mode:
Response code and flags:
Answer, authority, and additional data:
TTL:
Network view:
Observed at:
Command and tool version:
Repeat only the dimension being tested. Changing the name, type, resolver, network, and transport at once produces results that cannot be compared cleanly.
What these commands do not prove
A direct authoritative answer does not prove:
- every authoritative server agrees;
- recursive caches have refreshed;
- DNSSEC validates through the parent;
- the returned application destination works; or
- all networks can reach the server.
A recursive answer does not prove current authoritative state. A successful trace does not prove every resolver follows the same path. Keep each conclusion within the observer, server role, and time recorded.
Next step
Use these command patterns with the SERVFAIL diagnosis or the parent, child NS, and glue diagnosis. Stop before changing production state when the observations are incomplete or contradictory.
