dig commands for checking a DNS migration, with examples

The outputs below were captured from real example.com queries on September 27, 2026. DNS data changes, so copy the commands rather than treating the shown addresses or signatures as permanent. Use the DNS migration checker for a broader preflight.

Dig command examples for a DNS migration#

The useful shape is:

dig @server name type +options

• @server chooses exactly which resolver or authoritative server receives the query.
• name is the owner you are checking.
• type is one RR type such as A, MX, NS, SOA, TXT, CAA, DS, or DNSKEY.
• +norecurse clears the recursion-desired bit, so the server must answer from its own data or return a referral.
• +noall +answer prints a compact answer, but hides status and other sections; use full output when diagnosing an empty result.

ISC's current dig manual defines these flags. Build the first query here, then enable +norecurse in the builder.

dig @hera.ns.cloudflare.com example.com A

Query a specific nameserver and require the aa flag#

Before cutover, a normal lookup should still use the old provider. To test a new provider that is not delegated yet, query its assigned nameserver directly:

dig +norecurse @hera.ns.cloudflare.com example.com A

The captured response was:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7310
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       104.20.23.154
example.com.            300     IN      A       172.66.147.243

NOERROR says the query was processed successfully. aa is the Authoritative Answer flag: RFC 1035 section 4.1.1 says it applies to the name matching the question. ANSWER: 2 matches the two A records shown.

Do not accept a plausible address without aa. A recursive server or stale cache can return the right-looking value while the destination zone is absent. Query every destination nameserver, not only the first one, and repeat for representative apex, web, mail, verification, wildcard, and service-discovery names.

Dig command to check nameserver delegation at the parent#

A recursive dig example.com NS can come from cache or the child zone. Ask a parent authority to see the delegation it currently publishes. For a .com name:

dig +norecurse @a.gtld-servers.net example.com NS

The live response placed the delegation in the authority section:

;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 13

;; AUTHORITY SECTION:
example.com.    172800  IN  NS  hera.ns.cloudflare.com.
example.com.    172800  IN  NS  elliott.ns.cloudflare.com.

There is no aa flag here. This is a referral: the .com server is authoritative for com., while the delegated child data is returned in the AUTHORITY section. The additional section carries address records that help a resolver reach those nameservers. The 172800-second TTL is the cache lifetime observed for this delegation, not a universal constant.

For another top-level domain, do not guess its parent hostname. Run dig +trace or query the TLD's NS set, then address one of those authorities directly. The propagation checker complements this parent view by sampling what recursive resolvers currently observe.

dig @a.gtld-servers.net example.com NS

Use dig +trace to follow the delegation path#

dig +trace example.com A

+trace starts with the root and makes iterative queries through each referral. The capture progressed through these stages (long NS and signature sets shortened):

.               52326   IN  NS      a.root-servers.net.
;; Received 1097 bytes from 192.46.209.138#53 in 22 ms

com.            172800  IN  NS      a.gtld-servers.net.
com.            86400   IN  DS      19718 13 2 8ACBB0CD...
;; Received 1171 bytes from 192.112.36.4#53 in 146 ms

example.com.    172800  IN  NS      hera.ns.cloudflare.com.
example.com.    86400   IN  DS      2371 13 2 C988EC42...
;; Received 506 bytes from 192.12.94.30#53 in 233 ms

example.com.    300     IN  A       104.20.23.154
example.com.    300     IN  A       172.66.147.243
;; Received 179 bytes from 172.64.32.162#53 in 21 ms

Trace answers “which path did this run follow now?” It is not a worldwide propagation test and does not inspect every authoritative server. Local firewalls can also block the direct UDP or TCP traffic that trace needs. Use it to locate a broken referral, missing glue, or DNSSEC boundary, then query the relevant server directly.

Compare SOA serials across every authority#

The SOA summarizes a zone copy. Query all nameservers with compact output:

for ns in hera.ns.cloudflare.com elliott.ns.cloudflare.com; do
  printf '%s: ' "$ns"
  dig +norecurse +noall +answer @"$ns" example.com SOA
done

The live pair agreed:

hera.ns.cloudflare.com:    example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2415930514 10000 2400 604800 1800
elliott.ns.cloudflare.com: example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2415930514 10000 2400 604800 1800

The fields after SOA are primary server, responsible mailbox, serial, refresh, retry, expire, and negative-cache TTL. Equal serials are a quick consistency signal. Different serials can mean an update is still reaching secondaries, but values must be compared with RFC 1982 serial arithmetic, not naive integer ordering around wraparound.

Do not require the old and new providers to use the same serial. Managed providers can synthesize unrelated SOA values. Compare record content between providers; compare SOA serials among servers that are supposed to serve copies of the same provider zone.

Compare the old and new providers directly#

During a move, put both server sets in one loop. This captured comparison is real: example.com's former IANA authority still answered while the parent delegated to Cloudflare, and the two sources returned different A RRsets.

for ns in a.iana-servers.net hera.ns.cloudflare.com; do
  echo "-- $ns"
  dig +norecurse +noall +answer @"$ns" example.com A
done

-- a.iana-servers.net
example.com. 300 IN A 23.192.228.80
example.com. 300 IN A 23.192.228.84
example.com. 300 IN A 23.215.0.136
example.com. 300 IN A 23.215.0.138
example.com. 300 IN A 23.220.75.232
example.com. 300 IN A 23.220.75.245
-- hera.ns.cloudflare.com
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243

That difference is not an error in dig; @server bypasses current delegation. In your migration, define the expected translation before deciding whether a difference is acceptable. A proxied record, apex alias, or routing policy can legitimately produce different public addresses while still requiring explicit review. Use the DNS record diff for a structured comparison.

Check DNSSEC at the parent and child#

+dnssec sets the DNSSEC OK bit and asks the responder to include relevant DNSSEC records. It does not by itself validate the chain. Check the parent's DS separately from the child's DNSKEY and signed answers:

dig +norecurse +dnssec @a.gtld-servers.net example.com DS
dig +norecurse +dnssec @hera.ns.cloudflare.com example.com DNSKEY
dig +norecurse +dnssec @hera.ns.cloudflare.com example.com A

The parent DS capture included:

;; flags: qr aa; QUERY: 1, ANSWER: 2
example.com. 86400 IN DS    2371 13 2 C988EC423E3880EB...C83D245A
example.com. 86400 IN RRSIG DS 13 2 86400 20260930013256 ...

Unlike a delegation NS referral, DS belongs to the parent zone, so the parent returns it in the answer section with aa. Confirm that the child serves the DNSKEY selected by the DS and valid RRSIGs. A key-tag match alone is not cryptographic validation; digest, algorithm, signature, time, and denial-of-existence proofs matter too.

During a non-cooperating provider move, an old DS pointing to a key available only at the old authority can make validating resolvers return SERVFAIL. Follow the DNSSEC migration sequence, use the DNSSEC checker, and verify the parent after every registrar action.

dig @a.gtld-servers.net example.com DS

Check MX, TXT, CAA, and service records explicitly#

A website check does not cover email, certificate issuance, verification tokens, or service discovery. Query the types that exist in your source inventory:

for type in MX TXT CAA; do
  echo "-- $type"
  dig +norecurse +noall +answer @hera.ns.cloudflare.com example.com "$type"
done

The capture returned:

-- MX
example.com. 300 IN MX 0 .
-- TXT
example.com. 300 IN TXT "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
example.com. 300 IN TXT "v=spf1 -all"
-- CAA

MX 0 . is a null MX that explicitly says the domain accepts no mail. Two TXT strings are two records in one TXT RRset. The compact CAA query printed nothing; that alone does not distinguish a valid empty RRset from a timeout or error because +noall hid the header. Rerun a full query:

dig +norecurse @hera.ns.cloudflare.com example.com CAA

For your zone, also check _dmarc TXT, DKIM selector TXT, SRV owners, HTTPS/SVCB, CAA at relevant ancestors, delegated child NS, wildcards, and a name that should not exist. The zone diff tool helps derive the expected list from two zone snapshots.

Why dig ANY is not a command for all records#

There is no reliable dig command all records shortcut. An ANY query asks one owner name, not every name in a zone, and RFC 8482 permits a server to return one RRset, a subset, or a synthesized HINFO response.

The live proof is concise. This query:

dig +norecurse @a.iana-servers.net example.com ANY

returned only six A records. Separate MX and TXT queries to the same authority returned an MX record and two TXT records. ANY therefore omitted data that existed at that owner.

An authorized AXFR can transfer a whole zone, but most managed providers refuse public transfers, and a transfer still cannot represent provider-only controls. For migration inventory, use a provider API or export the DNS zone file, then query each expected type.

Read the output sections without guessing#

A full dig response has a header and four practical areas:

• Status: NOERROR means the name may exist with or without the requested type; NXDOMAIN means the queried name does not exist; SERVFAIL is a processing failure, often requiring DNSSEC and authority checks.
• Flags: aa marks an authoritative answer. rd says recursion was requested, ra says it was available, and ad says a validating recursive resolver considers the answer authenticated. ad is not expected from a direct nonvalidating authority query.
• QUESTION: confirms the exact name, class, and type sent. This catches search-suffix and typo mistakes.
• ANSWER: contains RRs that answer the question. Each row is owner, remaining TTL, class, type, then RDATA.
• AUTHORITY: can hold a referral NS set or the SOA proving a negative answer. Context decides which.
• ADDITIONAL: often contains glue or related addresses plus the EDNS OPT pseudosection. Useful data here is not a substitute for querying the RRset itself.

+short is convenient for scripts but strips the evidence needed to tell authoritative data from cache. For change-window logs, keep full output or at least the header plus answer and authority sections.

A migration query sequence that catches the common failures#