DNS Operations Manual
On this page
Separate query failure, differing answers and changes not yet observed. Record name, type, server and time, then compare authoritative, recursive and system resolution. Example domains are not mutation targets.
| Task | Start here |
|---|---|
| Name resolution fails | Read the response |
| Old IP after record change | Authority and cache |
| Check DNSSEC / encrypted DNS | Validation boundaries |
Keep status fields while diagnosing
Read a complete response first
# Query the configured resolver with response headers intact
Record status, flags, answer/authority, SERVER, and query time. In the example, TTL 300 is seconds; SERVER identifies the queried resolver.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
www.example.com. 300 IN A 192.0.2.10
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
# Ask a chosen recursive resolver the same question
@ selects the server. The display options retain status, answer, authority, and statistics for comparison; they do not alter records.
Choose the record type for the task
# Query IPv6 address records
If IPv4 works but IPv6 fails, inspect AAAA and the IPv6 path. No AAAA does not mean the name is absent.
# Read mail exchangers and their preference values
Lower preference numbers normally win. Resolve exchanger hostnames separately. Query TXT/CAA/CNAME explicitly; ANY is not an all-records inventory.
# Query PTR by converting an address to its reverse name
Substitute the real IP. PTR and forward records are maintained separately; neither proves the other is configured.
Check whether the application uses the same path
# Resolve through Linux NSS
Results may come from hosts, DNS, or other NSS modules. Differences from dig need source inspection; applications may use custom resolvers or DoH.
# Query systemd-resolved and inspect the selected link
Skip on systems not using resolved. Inspect per-link servers and routing domains with resolvectl status.
| Response | Meaning and next check |
|---|---|
| NOERROR + answer | An answer exists; inspect CNAME chain, type, TTL and SERVER |
| NOERROR + empty answer | May be NODATA for that type or referral; inspect authority |
| NXDOMAIN | Name absent in that DNS view; inspect negative caching |
| SERVFAIL | Resolution failed: DNSSEC, authority reachability, etc.; not proof of absent name |
| timeout | No timely response; inspect path, UDP/TCP 53 and server |
dig queries DNS; getent follows NSS, possibly including hosts; resolvectl targets systemd-resolved. These are different paths. +short is useful after status is understood. ANY does not enumerate all records; query the needed type.
TTL belongs to cache entries, not a global timer
An old record with TTL 120 was cached at t=0 and t=30. Authority changes at t=60; those old copies expire at t=120 and t=150 respectively.
Identify authority before comparing caches
# Find authoritative-server candidates for the zone
Check for delegation at subdomains; parent NS records do not prove authority over every child.
# Query the verified authority without recursion
Replace the server and inspect aa plus SOA/delegation information. Without aa, verify the zone. Compare all authorities to detect inconsistent deployment.
# Compare a recursive answer and its remaining TTL
Record query time. An updated authority with an old recursive answer may require old TTL expiry; negative caching can delay new records too.
# Follow delegation to locate a break between zones
This requires direct access to each DNS tier and does not reproduce enterprise forwarding, split DNS, or resolver cache state.
Flush only when evidence identifies the local cache
# Flush this host’s systemd-resolved cache
This is an optional remedy, not a prerequisite for every query. Recheck resolved and the application; other caches remain.
Replace the authoritative server and inspect AA/delegation/zone. +trace performs iterative lookup, not the production resolver’s cache, forwarders or split view. Different answers can reflect geography, views, cache, rotation or failure. Lowering TTL does not shorten copies already cached under an older TTL; negative answers can be cached too.
Preserve record identity and verify each layer
Read and save zone/record ID, name, type, value, TTL and routing policy before cloud changes. Update by record ID rather than accidentally adding another record. Alibaba Cloud UpdateDomainRecord requires RR, Type and Value. Preserve unrelated TXT values. Verify authority, intended resolver and application after API success.
Use resolvectl flush-caches only for the local resolved cache; it does not clear ISP, browser, container or remote resolver caches. For ACME DNS-01, verify delegation, TXT name and value; see certificates.
Separate transport encryption from DNSSEC validation
Requesting DNSSEC records is not validation
# Set DO to request related DNSSEC data
Inspect records such as RRSIG and the ad flag; dig does not validate the trust chain itself.
# Validate the DNSSEC result locally
Distinguish validated, unsigned, and validation failure. Check time, trust anchors, and network first; unsigned differs from broken signatures.
Keep the question fixed when comparing transports
# Compare the same query over TCP port 53
If TCP works while UDP times out, inspect filtering, fragmentation, and path issues. TCP DNS is not encryption.
# Query over DoT while verifying CA and server name
+tls enables TLS, +tls-ca checks trust, and +tls-hostname sets the expected identity. Diagnose handshake failures rather than disabling verification; confirm provider support.
kdig needs Knot tools with TLS support and a documented endpoint. +dnssec requests DNSSEC records; dig does not validate the chain itself. AD is the resolver’s validation claim, meaningful over a trusted path. delv validates with trust anchors and a correct clock. Encrypted DNS transport does not prove zone signing or protocol support at every IP.
BIND dig/delv · DNS negative caching RFC 2308 · Alibaba UpdateDomainRecord · Cloudflare DoT