DNS routing failure

Compare authoritative answers to recursive answers before you rewrite the zone. Failover context: region failover.

Symptoms

Clients hit the wrong load balancer, an old IP, or NXDOMAIN. Some networks work and others do not. A recent record change “did not take.” Failover records stay on the unhealthy endpoint. Split-horizon answers differ from the public zone. Certificate errors after a name change are often DNS plus TLS; see expired certificate.

Business impact

Clients cannot find the service, or they find a region you did not intend. Cached wrong answers last until each resolver’s TTL expires. There is no provider button that flushes every recursive resolver. A bad nameserver change at the registrar can take the whole zone off the air.

Immediate checks

1. Write the fully qualified name and the record type (A, AAAA, CNAME, ALIAS/ANAME if the product has it).
2. Find the parent delegation (registrar or parent zone) and the nameservers it lists.
3. Query those nameservers directly, then query at least two public resolvers.
4. Confirm which account owns the hosted zone. Duplicate zones in two accounts are a common cutover bug.
5. If the design uses failover, weighted, geolocation or GTM policies, check health-check state before you assume the record is wrong.

Do not quote a “default TTL” from memory. Read the TTL on the record you are looking at. Route 53, Azure DNS, Cloud DNS and Alibaba Cloud DNS all let you set TTL per record; see each working-with-records page in Official sources.

Provider commands and console paths

AWS Route 53. Hosted zones, Records. Failover: DNS failover. Records: working with records.

aws route53 list-hosted-zones-by-name --dns-name example.com
aws route53 list-resource-record-sets --hosted-zone-id Zxxxxxxxx
aws route53 get-health-check-status --health-check-id ID

Resolver test (your workstation):

dig example.com A +norecurse @ns-xx.awsdns-xx.com
dig example.com A @8.8.8.8

Azure DNS. DNS zones, record sets. If Traffic Manager is the public name, diagnose that profile as well (Traffic Manager).

az network dns zone show --resource-group RG --name example.com
az network dns record-set list --resource-group RG --zone-name example.com
az network dns record-set a show --resource-group RG --zone-name example.com --name www

CLI: az network dns record-set.

Google Cloud DNS. Cloud DNS, zones, record sets. Policy behaviour: routing policies.

gcloud dns managed-zones describe ZONE
gcloud dns record-sets list --zone=ZONE
gcloud dns record-sets describe www.example.com. --type=A --zone=ZONE

Alibaba Cloud DNS. Alibaba Cloud DNS console, domain, resolution settings. GTM if you attached it.

aliyun alidns DescribeDomainRecords --DomainName example.com

If your CLI build rejects that product prefix, use the console and Alibaba Cloud DNS help. Do not invent extra flags.

Interpretation

Authoritative answer is correct, public resolvers are stale: cache. Wait for the TTL that was on the previous record, or ask users on a corporate resolver to flush that resolver only.

Authoritative answer is wrong: fix the zone you queried. Do not edit a look-alike zone in another account.

Authoritative NXDOMAIN but the registrar still shows old nameservers: delegation was never moved, or you queried a zone that is not delegated.

Failover record still returns primary: health check still healthy, or the check is probing a path that does not match user traffic.

Some regions get different answers: geolocation or latency policy is doing what you configured. That is not a bug unless the map is wrong.

CNAME at the zone apex: many DNS products reject that. Use the alias/ANAME feature the product documents, or a different name.

Safe mitigation

Edit the record in the delegated hosted zone. Keep a second record or a known-good previous value until the new answer is visible at the authoritative servers.

If failover should have fired, fix or fail the health check so the documented policy can take over. Prefer that over a hand-edited A record that bypasses the policy, unless the DR plan says to do the hand edit.

For registrar nameserver changes, change them once, to the nameservers the hosted zone page shows, and wait for the parent TTL. Do not bounce between two DNS products.

Risky actions to avoid

Do not delete the hosted zone.

Do not change nameservers at the registrar as a way to “clear cache.”

Do not set TTL to an undocumented value you cannot explain. Use a TTL the product accepts and that your last drill used.

Do not point the name at a random IP from an old runbook.

Do not disable DNSSEC at the parent to debug unless you know how to re-enable it and you are actually looking at a bogus DS record.

Validation

Authoritative dig returns the intended RDATA. Two public resolvers converge after the previous TTL. HTTP or TLS checks against the name reach the intended origin. If you changed failover, confirm both the healthy and forced-unhealthy cases, then restore the primary if this was a test.

Prevention

1. One delegated public zone per name, with change control. Two products answering the same name is a split-brain.
2. Store record changes in the same pipeline as the load balancer or origin change.
3. Drill failover, including the health-check path the product actually probes.
4. Monitor the name from outside the VPC. In-VPC resolvers can look healthy while public DNS is wrong. Vigiles is the sister site for external name and HTTP checks.
5. Document the TTL you configured. Do not rely on a provider default you did not look up; TTL is whatever Route 53, Azure DNS, Cloud DNS or Alibaba DNS publishes for that record type.