Dipak D. Kuthe · Originally published July 12, 2026
If your website stops working after a DNS change, compare the answer from the authoritative nameservers with the answer your users receive from their recursive resolver. If the answers differ, check the cache and the delegation. If both answers are correct, test HTTPS or the application itself before editing more records.
Who answers a DNS query?
A device usually sends a question to a recursive resolver operated by the business, an ISP, or a DNS provider. The resolver may answer from its cache. On a cache miss, it can follow referrals from the DNS root to the top-level domain and then to the authoritative servers for the requested zone. An authoritative server answers from that zone’s data. It may also return an alias that requires another lookup.
The registrar is where you manage the domain registration and typically submit changes to the parent delegation. The DNS host publishes the zone. Those may be different companies. Changing a record in a provider’s dashboard has no public effect if that provider’s nameservers are outside the active delegation. Internal DNS can intentionally serve different answers, so compare an affected office client and an approved external test point only for names intended to be public. IETF DNS terminology
Records worth inventorying
| Record | What it controls | What to check |
|---|---|---|
| A and AAAA | IPv4 and IPv6 addresses for a name | Check both when moving a website. A stale AAAA answer can affect IPv6 users even when A is correct. |
| CNAME | An alias to another DNS name | Check the target as well as the alias. A standard CNAME cannot coexist with ordinary records at that same name, so use the DNS provider’s documented apex configuration if needed. |
| MX | Incoming mail destinations | Compare the full set of targets and preferences with the mail provider’s instructions. Lower preference numbers are preferred. |
| TXT | Text used by applications and verification workflows | Preserve ownership verification and mail authentication records. Some providers use a CNAME to delegate DKIM selectors. |
| NS | Nameservers for a zone or delegated child | Compare the parent delegation with the nameservers expected to serve the zone. |
| SOA | Zone authority metadata, including a serial and negative-cache settings | Check SOA when authoritative servers disagree or a newly created name still appears missing. |
| DS | Parent-zone data linking a delegation to the child zone’s DNSSEC keys | Coordinate changes with the DNS host and registrar during a signed-zone migration. |
SPF authorizes sending infrastructure, DKIM provides a verifiable signature, and DMARC evaluates alignment with the visible From domain and publishes policy and reporting preferences. These controls help address spoofing. Inbox placement still depends on other factors. Follow the mail provider’s exact record names and values and test inbound and outbound mail separately. DNS record definitions · Microsoft email authentication guidance
Plan changes around what is already cached
TTL is expressed in seconds. For example, if an A record was cached with a TTL of 3600, lowering the authoritative TTL to 300 does not shorten the older copy’s remaining lifetime. Lower the TTL at least one previous TTL interval before a planned cutover and verify the lower TTL on the authoritative servers. Account separately for other records in the lookup chain, including aliases and delegation records. Negative answers can be cached too. A resolver that cached NXDOMAIN shortly before you created a name can still report it missing. Some resolvers can also serve stale data when they cannot refresh an expired answer. Negative caching · Serving stale data
Before editing, export or record the existing values, TTLs, and provider-specific settings. Identify who can reverse the change and keep the old endpoint available through the transition when possible. Change one dependency at a time. After verification from representative networks, restore normal TTLs. Avoid changing website addresses, mail records, and nameserver delegation in the same window unless the migration requires it.
Protect the domain and verify DNSSEC separately
Protect registrar and DNS-host accounts with MFA and individual access. Limit edit rights, review change logs, and track domain renewal. DNSSEC lets validating resolvers check the origin and integrity of signed DNS data. It does not encrypt DNS traffic or replace HTTPS. The parent DS must match the intended child signing key. A stale DS after a provider migration can cause validating resolvers to return SERVFAIL even when the new authoritative servers answer directly.
Follow the provider’s DNSSEC migration process and verify the parent DS and child DNSKEY before retiring the old service. Validate with a trusted validating resolver or a validation tool such as delv. The dig +dnssec option requests DNSSEC records. Seeing signatures in that output alone does not establish successful validation. IETF DNSSEC overview · ISC BIND command reference
If you operate a validating recursive resolver, check how to verify a resolver’s root trust anchor. Domain owners should use the DS and DNSKEY checks above for their own zone.
Fictional example: the website still opens the old host
Illustrative troubleshooting example. CoreSecTech did not perform this cutover.
A company moves www.example.com from 192.0.2.10 to 192.0.2.20. Some employees still see the old site. The names and addresses below are placeholders. Replace the authoritative and recursive server addresses with the real addresses for your approved test. Query each delegated authoritative server in turn.
dig @192.0.2.53 www.example.com. A +norecurse
dig @192.0.2.53 www.example.com. AAAA +norecurse
dig @192.0.2.54 www.example.com. A
dig @192.0.2.54 www.example.com. AAAAThe equivalent Windows queries use Resolve-DnsName:
Resolve-DnsName www.example.com. -Type A -Server 192.0.2.53 -DnsOnly -NoHostsFile -NoRecursion
Resolve-DnsName www.example.com. -Type AAAA -Server 192.0.2.53 -DnsOnly -NoHostsFile -NoRecursion
Resolve-DnsName www.example.com. -Type A -Server 192.0.2.54 -DnsOnly -NoHostsFile
Resolve-DnsName www.example.com. -Type AAAA -Server 192.0.2.54 -DnsOnly -NoHostsFile| Observation | Next action |
|---|---|
| Every authoritative server returns the new A with the authoritative answer flag in dig, while one resolver still returns the old A | Record the remaining TTL and retest that resolver after it expires. Keep the old host serving during the transition if possible. |
| Authoritative servers disagree or an answer lacks the authoritative flag | Check which servers the parent delegates to and whether the intended zone was published to each server. |
| A is correct but AAAA still points to the retired host | Check the new host’s IPv6 support. Correct the AAAA record if IPv6 is supported, or remove the obsolete AAAA through an approved change if the service is meant to be IPv4-only. |
| DNS answers match the plan, but the website still fails | Verify HTTPS for the intended hostname, including certificate validity, the expected application response, and any CDN or proxy configuration. |
Rollback: If the new endpoint fails the agreed HTTPS or application check, restore the exact previous record values while keeping the old endpoint available. Re-query every authoritative server and both test resolvers, then retest HTTPS. Caches can retain the new answer after the rollback, so keep both endpoints healthy if possible and record which resolver still sees which value. Leave MX and mail-authentication records untouched during a website-only rollback. Microsoft Resolve-DnsName reference · Business VLAN verification guide