AWS Identity Verification AWS DNS Route 53 Configuration Troubleshooting

AWS Account / 2026-07-01 14:50:58

Chapter 1: Why Route 53 DNS Troubleshooting Feels Hard

Most Route 53 problems don’t come from “one broken button.” They usually come from small mismatches between what you configured and what the rest of your infrastructure actually expects. DNS is unforgiving: if a record points to the wrong target, uses the wrong type, or doesn’t match what your domain registrar is set to, everything can look “up” in the AWS console while users see errors.

That’s why a good troubleshooting approach is not random clicking. You need a process: confirm which DNS zone is being queried, confirm each record’s values, confirm TTL/propagation behavior, and confirm the endpoint behind the record is reachable. This article walks through a practical, step-by-step way to troubleshoot AWS DNS Route 53 configuration issues—without relying on guesswork.

AWS Identity Verification Chapter 2: Clarify the Symptom First

Before you touch Route 53, write down what the user experiences. Different symptoms point to different layers of the problem.

Browser shows “DNS_PROBE_FINISHED_NXDOMAIN”: likely the domain name doesn’t exist in the resolved zone, or you’re querying the wrong authoritative nameservers.
“DNS_PROBE_FINISHED_BAD_ADDRESS” or connection failures: the name resolves, but the IP/target is wrong or the service isn’t reachable.
Server responds with the wrong site: CNAME/alias targets point somewhere else, or multiple records cause unexpected resolution.
Intermittent success: caching/TTL mismatch, split-horizon DNS, or multiple records being returned with inconsistent answers.
Only some geographies/countries fail: CDN/WAF routing differences, or Geo DNS logic in records.

Also record the hostname that fails (example: www.example.com vs example.com), and the record type you expect (A, AAAA, CNAME, MX, TXT, or an alias). DNS issues often happen because people fix one name but ignore another.

Chapter 3: Build a Mental Model of Route 53

Route 53 isn’t “the domain.” It’s the service that answers DNS queries for a zone. There are two big concepts that matter for troubleshooting:

3.1 Hosted zone vs delegated domain

A hosted zone in Route 53 contains records that Route 53 will answer when it is authoritative. But the domain’s delegation is decided at the registrar (or by parent DNS). If your registrar doesn’t point to the hosted zone’s name servers, Route 53 won’t be consulted.

3.2 Record selection rules

DNS record types behave differently:

AWS Identity Verification A/AAAA: map a name directly to an IP.
CNAME: map a name to another name.
Alias (Route 53 specific): like A/AAAA but can target AWS services; it still returns an IP.
MX: controls mail delivery; priority values matter.
AWS Identity Verification TXT: common for verification (SPF, DKIM, domain verification).

When you troubleshoot, always ask: “Which record type is being returned for this name?” and “What final target is it pointing to?”

Chapter 4: Confirm You’re Querying the Right DNS

The fastest way to waste time is to inspect the correct Route 53 hosted zone while the world is querying a different one. First confirm which authoritative servers are being asked.

4.1 Check name servers at the registrar

Log in to your domain registrar and look for the nameserver or delegation setting. It should match the name servers** assigned to the hosted zone in Route 53.

If you recently updated nameservers, allow time for registrar-level and resolver-level caching. But note: even after propagation, some resolvers can continue caching old data.

4.2 Use DNS queries to confirm authority

From a terminal or DNS lookup tool, perform queries for the failing hostname. You want three key pieces:

Does the domain resolve at all?
What are the record answers (IP/target/name)?
Which nameserver is answering?

If your query results show that answers are coming from unexpected authoritative nameservers, stop adjusting Route 53 records and fix delegation first.

Chapter 5: Verify Hosted Zone Basics in Route 53

Once you confirm that Route 53 is authoritative, validate the hosted zone itself.

5.1 Make sure you’re editing the correct zone

Common mistake: you have multiple hosted zones (for the same domain or for subdomains). For example, you might have a hosted zone for example.com and another for dev.example.com. If you change records in the wrong one, nothing will fix the symptom.

5.2 Confirm record names match exactly

DNS names are exact. In Route 53, the record name is relative to the zone. For example, in a hosted zone for example.com:

record name = www means www.example.com
record name = (blank) usually means the apex: example.com

If you intended to configure the apex record but added it under www, you’ll get partial or confusing results.

5.3 Watch out for record duplication or overlapping rules

If you enabled routing policies like failover, weighted, geolocation, or latency-based routing, multiple records might exist for the same name and type. Route 53 will return different records depending on the routing policy evaluation. Troubleshooting becomes harder unless you identify which routing policy is active.

Chapter 6: Common Record-Level Mistakes (and How to Fix Them)

Here are the mistakes you’ll see most often, along with concrete verification points.

6.1 A record points to the wrong instance or IP

If you use A records to point to an EC2 instance, confirm that the instance is actually running and has the expected public IP (or that you’re using Elastic IP). If your instance restarted and the public IP changed, the A record will become stale.

Fix path:

Prefer Elastic IP for stable A record targets.
Or switch to an alias to a stable AWS endpoint (when appropriate).
Update the A record with the correct IP.

6.2 CNAME chain errors

A CNAME should map one name to another canonical name. Problems happen when:

The CNAME target is misspelled or ends in a different domain.
You chain multiple CNAME records unintentionally and the final target is misconfigured.
You create conflicts like using CNAME at the same name where other record types exist.

How to verify: query the CNAME and also resolve the final target. Many “DNS works but site fails” issues are actually “final A record is wrong.”

6.3 Route 53 alias misconfiguration

Route 53 alias records are frequently used for AWS resources such as ELB/ALB, CloudFront, and API Gateway custom domains. The alias must target the correct resource and the correct hosted zone ID (Route 53 chooses this for you in the UI, but mistakes can still happen when selecting similar resources).

Check: does the alias return the expected IPs when you query the name? If yes, DNS is likely fine and the problem is the application/network behind it.

6.4 TTL expectations vs reality

TTL values control how long resolvers cache answers. If you changed an A record, but TTL was high (for example 300s or 3600s), you might see updates slowly.

Troubleshooting tip: lower TTL temporarily before planned changes. For Route 53 alias records, TTL may be managed differently, but caching still matters.

6.5 MX record priorities and domain verification TXT

Mail and verification records are common sources of “it should work” issues.

MX priorities: lower number means higher preference. If all MX records point to the wrong provider or wrong priority ordering, mail fails or uses fallback routing.
TXT for verification: providers often expect an exact token and sometimes a specific record name (apex vs subdomain).

Always match the exact values provided by the service (not just the general concept).

Chapter 7: Troubleshoot the Entire Resolution Path

Think in layers: delegation → authoritative answer → record value → final target reachability.

7.1 Layer 1: Delegation

If delegation is wrong, the rest doesn’t matter. Confirm that your registrar nameservers are correct.

7.2 Layer 2: Authoritative answer

Confirm the query returns answers from Route 53 for your hosted zone. Check for NXDOMAIN or SERVFAIL. If you get NXDOMAIN, the name might not exist in that zone.

7.3 Layer 3: Final record target

For CNAME, resolve the CNAME target. For alias, confirm the alias resolves to the expected AWS endpoint IPs.

7.4 Layer 4: Application/network reachability

Even perfect DNS doesn’t guarantee success if the service behind it can’t accept connections.

ALB/EC2 security group denies traffic from the internet.
ACM certificate doesn’t match the hostname (TLS errors).
CloudFront distribution is configured with incorrect origin or behaviors.
WAF rules block the user’s requests.

If you confirm DNS resolves correctly but users still fail, shift your focus from Route 53 to the target service.

Chapter 8: Case Studies You Can Match to Your Situation

Below are realistic scenarios that map directly to common Route 53 configuration failures.

8.1 “I updated Route 53 but the site didn’t change”

Most likely causes:

You edited the wrong hosted zone.
The registrar nameservers still point elsewhere.
You updated one hostname but users are hitting another (apex vs www).
TTL caching delayed the change longer than expected.

Fix approach: verify delegation, then query the exact hostname from an external resolver, then confirm the returned record values.

8.2 “DNS resolves, but I get certificate errors”

DNS might be correct, but TLS is failing. Common causes include:

ACM certificate doesn’t cover the hostname.
ALB listener is attached to the wrong certificate.
CloudFront is using a certificate that doesn’t include the custom domain.

AWS Identity Verification Fix approach: confirm the certificate coverage for the exact hostname, not just the parent domain.

8.3 “Mail verification passes, but emails don’t arrive”

Verification is often handled separately from delivery correctness. For MX issues:

MX records might point to the wrong hostnames.
Priority order might be wrong.
There could be missing SPF/DKIM/DMARC alignment required by the receiving provider.

AWS Identity Verification Fix approach: validate MX values and then confirm the mail provider’s recommended DNS set.

Chapter 9: A Practical Troubleshooting Checklist

If you want a repeatable process, use this checklist in order:

9.1 Confirm what hostname and record type you need

Is it apex (example.com) or subdomain (www.example.com)?
Which record type should exist (A, CNAME, alias, MX, TXT)?

9.2 Confirm Route 53 is authoritative for the domain

Registrar nameservers match the Route 53 hosted zone.
AWS Identity Verification DNS queries show answers coming from the expected authoritative servers.

9.3 Confirm the hosted zone you edited is the one being queried

Look for overlapping hosted zones for similar domains.
Verify record names are correct relative to the zone.

9.4 Confirm the record values are correct

A/alias targets match the current IP/service.
CNAME chains end at the correct final hostname.
Routing policy (weighted/failover/geo/latency) matches your expectation.

9.5 Confirm the endpoint behind DNS is reachable

Security groups allow traffic.
ALB/CloudFront/origin configuration is correct.
Certificates cover the hostname.

Chapter 10: Advanced Pitfalls to Watch For

AWS Identity Verification Once the basics are correct, the remaining issues often come from less obvious configuration differences.

10.1 Split-horizon DNS (public vs private hosted zones)

If you created a private hosted zone and test from within the VPC, you might see different answers than users on the public internet. Route 53 supports both public and private hosted zones. If a private zone overlaps your name, internal clients might resolve differently.

Fix approach: confirm which hosted zone applies to your resolver and network location.

10.2 Health checks and failover routing

For failover routing policies, Route 53 uses health checks to decide which record is active. If a health check is failing due to firewall rules or an incorrect path, Route 53 may keep returning the “failover” record.

Fix approach: check health check configuration and target reachability from AWS.

10.3 Weighted records and unexpected load distribution

AWS Identity Verification Weighted routing can cause “it works sometimes” behavior. If you accidentally set weights that split traffic in a way that exposes a broken endpoint, you may see intermittent errors.

Fix approach: confirm weights, then temporarily adjust to ensure the correct endpoint receives traffic.

AWS Identity Verification 10.4 Internationalized domain names (IDN) edge cases

Some hostnames include Unicode characters. DNS and TLS must handle punycode correctly. If your domain contains IDN characters, verify that both DNS records and certificates match the exact hostname representation.

Chapter 11: Safe Change Strategy for Route 53

You rarely want to “fix” DNS by making multiple changes at once. The safest approach is incremental:

Change one record or one routing policy at a time.
Use low TTL before a planned switch when possible.
Test from multiple networks (for example, a home connection and a different ISP if feasible).
Keep a record of previous values so rollback is fast.

When a problem is live, reduce variables. If you update nameservers and record values simultaneously, it becomes impossible to know which change caused the effect.

Chapter 12: Wrap-Up—What “Good” Troubleshooting Looks Like

Effective AWS Route 53 DNS troubleshooting follows the path of responsibility: confirm delegation, confirm authoritative answers, confirm the specific record value returned, and then confirm the target service is actually able to serve traffic for that hostname. When you follow that sequence, you stop relying on luck and start narrowing the issue quickly.

Most importantly, don’t treat DNS as isolated. DNS is just the address book. If the address is wrong, users fail. If the address is correct but the building can’t be entered, users still fail—just with a different symptom. Separate those layers, and troubleshooting becomes straightforward.