A DNS change can be correct at the authoritative source and still be absent from a recursive cache that has not refreshed. It can also be wrong on one authoritative server, hidden behind a broken parent delegation, or intentionally different for clients on separate networks. All four situations can produce the familiar report that the domain works for one person and fails for another. Calling every disagreement propagation skips the diagnosis. A useful DNS checker records what was queried, where the answer came from, and which part of the resolution path the result can actually test.
The central limitation is simple: one DNS response is one observation. It may come from a recursive resolver's cache, a forwarding chain, or an authoritative server queried directly. It says nothing certain about caches elsewhere. Even several public resolvers queried from one application do not represent every network or every node behind an anycast address. Verification becomes reliable when the team separates authority, delegation, recursion, client context, and service behaviour instead of compressing them into a single percentage.
Start with the question the check must answer
An authoritative check asks what the zone currently publishes. A delegation check asks which nameservers and DNSSEC delegation data the parent zone exposes. A recursive check asks what a particular resolver returns after applying its cache and policy. A client-path check asks what a user on a real device and network experiences. A service check asks whether the application behind the name works after DNS resolution. These are related tests, but success in one does not guarantee success in the next.
Write the expected outcome before running commands. For an A-record migration, that may be a set of old and new addresses during a controlled overlap. For MX, order and priority matter. For TXT, exact quoting and string assembly can matter to the consuming protocol. For a CDN, several valid address sets may be expected. Without a defined acceptable result, a checker may label intentional variance as failure or treat any syntactically valid answer as success.
What DomScan DNS Lookup observes
DomScan GET /v1/dns performs an on-demand DNS-over-HTTPS lookup through a primary recursive service with a second service as fallback if the first request fails. It does not query both resolvers and compare them. The default record type is A; supported specific types include A, AAAA, NS, MX, TXT, CAA, SOA, CNAME, PTR, SRV, HTTPS, and SVCB. The response includes records, status, observed TTL values, query duration, check time, an upstream DNSSEC-authentication signal, and limited warnings for selected record types.
The DNS Lookup Tool calls GET /v1/dns/all. That route queries A, AAAA, NS, MX, TXT, CAA, SOA, HTTPS, and SVCB in parallel through the same recursive fallback path and builds a current summary. It can flag missing IPv6 parity, suspicious private addresses in public A or AAAA data, and selected MX-priority issues. It is not an authoritative-zone audit, a comparison of independent resolvers, or a geographic propagation test. Its checked_at and served_by metadata describe this request, not a worldwide observation.
A success status with an empty answer can mean that the name exists but has no record of the requested type. NXDOMAIN means that the queried name does not exist according to the returned response. An error or timeout is not evidence that the name or record is absent. The API response itself also permits short HTTP caching, so a verification workflow that requires an uncached upstream observation should account for application and edge caches rather than assuming every repeated request forces new recursion.
Check authority before recursive caches
Find the nameservers delegated by the parent zone, then query each authoritative server directly. A direct query with recursion disabled isolates the data served by that authority from a public recursive cache. Compare the full relevant RRset, response code, authoritative-answer flag, and SOA record. If the authorities disagree, waiting for caches will not make the underlying zone consistent. Correct the publication or secondary-server problem first.
# Discover the resolution path and parent delegation
dig +trace example.com NS
# Query each delegated authority without recursion
dig @ns1.provider.example example.com A +norecurse
dig @ns2.provider.example example.com A +norecurse
# Compare a recursive observation separately
dig @1.1.1.1 example.com ASOA serial numbers help when the zone operator uses them consistently. Secondary servers use the serial to decide whether a newer zone is available, and comparisons follow the wraparound arithmetic defined by RFC 1982. Equal serials are useful supporting evidence, but they do not replace comparison of the RRset you changed. Managed DNS systems can generate or distribute zones differently, and a serial alone does not prove that every response path is healthy.
TTL is a cache instruction, not a global countdown
A TTL states how long a record may be cached before the source should be consulted again. Resolvers cache the old record at different times, so their entries expire at different times. Lowering the TTL shortly before a migration does not shorten copies that were already cached with the older, longer TTL. Reduce it at least one old-TTL interval before the change if the operation depends on faster refresh, and verify the lower value at the authorities before starting the migration.
The TTL shown in a recursive response often reflects remaining cache life, but it is not a dependable clock for the entire internet. Resolver prefetch, forwarding layers, cache policy, and refreshed answers can change what appears. RFC 8767 also permits a resolver to serve expired data when authoritative refresh fails, with a short TTL in the stale response. A stale answer during an outage is therefore not necessarily proof that the resolver simply ignored the zone's TTL.
Negative answers have their own caching. RFC 2308 distinguishes NXDOMAIN, where the queried name does not exist, from NODATA, where the name exists but lacks the requested type. The negative cache lifetime is carried through the zone's SOA data and is based on the lower of the SOA MINIMUM value and the SOA record TTL. If a new hostname was queried before it existed, that cached NXDOMAIN can remain after the new record is published.
Different answers may be intentional
DNS providers and applications can return different valid answers for load distribution, failover, or policy. A round-robin RRset may arrive in a different order while containing the same values. A CDN can tailor an answer to the recursive resolver's network. EDNS Client Subnet, defined in RFC 7871, allows a resolver to pass limited client-network information that an authoritative service may use for a tailored response. Split DNS can give internal and external clients deliberately different zones.
Compare answers against the intended policy, not a single golden IP. Record the complete RRset and ignore order where order has no protocol meaning. Note whether the resolver used EDNS Client Subnet and which source network generated the query. For location-sensitive services, test the application from actual client networks as well as examining DNS. Two valid addresses can still lead to different service health, TLS configuration, or content.
Delegation, glue, and DNSSEC form a separate chain
The parent zone delegates a child through NS records. The child zone also publishes an NS RRset at its apex. During a nameserver migration, parent and child data can disagree. Resolvers follow the parent delegation, so editing only the child apex does not move the delegation. A lame delegation occurs when the parent points to a server that is not authoritative for the child or cannot answer correctly. Query the parent and every delegated server rather than relying on the NS answer returned through one recursive cache.
Glue addresses break circular dependencies when a delegated nameserver name lies inside the child being delegated, such as ns1.example.com serving example.com. Glue belongs in the parent-side delegation data and is not a normal authoritative answer from the child zone. Missing or stale glue can make the authority unreachable even when the child zone contains a correct A or AAAA record for the nameserver. The IANA nameserver requirements provide a useful model for testing delegations and authoritative consistency.
For a signed zone, also check the DS record at the parent and the DNSKEY and signatures in the child. A stale DS after changing or removing signing keys can cause validating resolvers to return SERVFAIL while nonvalidating paths appear to work. DomScan's dnssec_validated field reflects the Authenticated Data bit from its upstream recursive response. Under RFC 4035, that bit means the resolver considered the relevant RRsets authentic. The signal is meaningful only within a trusted relationship to that resolver and does not prove every resolver validates the same path.
CNAME checks need the target and the owner name
A CNAME makes one owner name an alias of another. RFC 2181 clarifies that a CNAME owner cannot carry other ordinary data. This is why a standards-based CNAME cannot sit at a zone apex that must also contain SOA and NS records. Provider features called ALIAS, ANAME, or CNAME flattening synthesize other record types and are not CNAME records in the public answer. Verify the actual response rather than assuming the provider's configuration label describes wire-format DNS.
A dangling CNAME points at a target that no longer resolves or no longer belongs to the expected service. The DNS symptom alone does not prove takeover is possible. Claimability depends on the target provider's current account and resource rules. Query the alias and final target, inspect the service response safely, and follow the provider's documented verification process. DomScan can show a CNAME observation when that type is requested, but it does not certify whether the external target can be claimed.
Real multi-vantage testing is a separate workflow
A meaningful multi-vantage test runs probes from independent source networks or devices. Querying an anycast resolver address from one server reaches the route selected for that server; attaching city names to repeated requests does not move the packets to those cities. A robust design uses controlled agents in the regions and networks that matter, or trusted remote measurement infrastructure, and records the egress network for each probe. Public recursive resolvers can be part of the sample, but they are not geographic sensors by name alone.
For each probe, retain query name and type, resolver address, source vantage, UTC time, transport, response code, flags, answer and authority RRsets, TTLs, and whether ECS was present. Test actual client paths such as corporate DNS, home broadband, mobile data, and VPN exits when those populations matter. A finite sample can find disagreement; it cannot prove universal agreement. Phrase the result as all tested probes matched the expected policy, followed by the tested scope.
A practical DNS change procedure
- Record the current parent delegation, DS data, authoritative nameservers, target RRsets, SOA serials, and old TTLs before changing anything.
- If a shorter cache window is required, lower the TTL early enough for the old TTL to expire and confirm the new TTL directly at every authority.
- Validate the proposed record syntax and service dependencies. Check CNAME targets, MX priorities, TXT consumers, certificate coverage, and IPv4 or IPv6 expectations as relevant.
- Apply the change through the system that actually controls the authoritative zone. Avoid parallel manual edits in multiple control planes.
- Query every delegated authoritative server with recursion disabled and compare the complete expected RRsets, response codes, and DNSSEC data.
- Check the parent delegation and glue separately if nameservers or signing keys changed. A correct child zone cannot repair incorrect parent data.
- Sample recursive resolvers and real client networks during the cache window. Record the scope and allow for intentional answer variance.
- Test the service itself, restore the normal TTL when the migration is stable, and save the evidence and change record for later review.
Do not use a fixed rule such as wait for twice the TTL as proof of completion. It can be a conservative observation window for a particular runbook, but it cannot account for unknown pre-change queries, negative caches, serve-stale behaviour, forwarding chains, or clients that use private DNS. Completion criteria should name the authorities, recursive samples, client networks, and application checks that must pass.
How DomScan DNS History fits
DNS History is a beta observation log populated by successful DomScan DNS lookups. It stores day-level windows for record values and can emit added and removed events for observed types. A successful empty answer can close values that DomScan previously considered current for that type. Dates have day-level precision, and additions and removals can share a date. The current_records field means latest state in this observation set, not a direct statement from every authoritative server.
The history has no external passive DNS feed and does not observe the domain continuously. Changes between lookups can be missed entirely. Gaps do not prove stability, first_seen is first seen by DomScan rather than first existence on the internet, and last_seen is not an exact deletion time. TTL drift is intentionally not treated as a change because recursive answers commonly expose a decreasing cache TTL. Use the log to compare DomScan observations, then run direct authority and resolver checks for the incident or migration in front of you.
Domain Health and Domain Monitor answer different questions
Domain Health is a separate on-demand assessment. It checks current DNS configuration along with TLS, email, DNSSEC, CAA, web-security, registration, and other health signals. Its DNS work also uses the recursive fallback path, so it is not a continuous authoritative-zone monitor or a geographic propagation proof. Use it to broaden a current review after verifying the exact DNS change at the authorities.
Domain Monitor tracks registration availability, expiry, and registration-status changes for domains in an account. It does not continuously compare DNS RRsets, certificates, WHOIS fields, or application responses. If DNS drift needs alerting, configure a dedicated monitoring system with the authoritative and recursive probes, expected RRsets, client vantage points, and notification ownership required by the service. Do not infer DNS monitoring from the presence of a domain in DomScan's portfolio.
Where DomScan fits
Use DNS Lookup for a current recursive view of major record types and GET /v1/dns when an integration needs one specific type plus response metadata. Use DNS History for the limited day-level values DomScan has previously observed. Run Domain Health for a broader current-state assessment. For authority, delegation, multi-vantage, and ongoing RRset monitoring, add the direct DNS tools and external probes that match the operational question.
Primary references: RFC 1034 and RFC 1035 define the DNS model and protocol. RFC 2181 clarifies RRset, TTL, and CNAME rules. RFC 2308 defines negative caching. RFC 4035 covers DNSSEC validation signals. RFC 7871 explains ECS-tailored answers, and RFC 8767 covers stale data during refresh failure.