Learning guide · Intermediate

DNS diagnostic commands

Use dig, delv, or Resolve-DnsName to separate recursive observations, referrals, authoritative answers, DNSSEC validation, and transport behavior.

Written by VMCSoft Digital. Reviewed by VMCSoft Digital technical review.

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 as NOERROR, NXDOMAIN, or SERVFAIL;
  • flags, especially rd, ra, and ad;
  • answer, authority, and additional sections;
  • remaining TTLs;
  • the SERVER line; 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:

  1. root response referring to the top-level domain;
  2. parent response referring to the child zone;
  3. glue or other address data included with referrals; and
  4. 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.