Why Route 53 mistakes are common

Route 53 is powerful, but it has quirks that trip up even experienced AWS engineers. It behaves differently from traditional DNS in several important ways — alias records, hosted zone delegation, and the tight coupling between Route 53 and other AWS services all create opportunities for subtle misconfiguration.

The AWS console makes it easy to create records without fully understanding the implications. There's no "are you sure?" when you create a CNAME at the apex. There's no warning when your alias target is deleted. And when things break, the failure modes are often silent — traffic just stops arriving, with no error in the Route 53 console to tell you why.

Mistake #1: Using CNAME at the zone apex

DNS standards (RFC 1034) forbid CNAME records at the zone apex — that's your bare domain, like example.com. A CNAME at the apex would conflict with the SOA and NS records that must exist there. This isn't a Route 53 restriction; it's a fundamental DNS rule.

Route 53's solution is the alias record. An alias looks like a CNAME in practice — it points one name at another resource — but it's resolved server-side by Route 53 before returning the answer. From the client's perspective, it looks like a normal A or AAAA record. There's no CNAME chain, no extra lookup, and no RFC violation.

The mistake: teams new to Route 53 try to create a CNAME for their root domain pointing to their ELB or CloudFront distribution. If they use the console, they might get an error or they might accidentally create it as a subdomain record instead. If they use Terraform or the CLI without understanding the distinction, they might create a technically valid but functionally broken configuration.

The fix: Use an alias record (type A or AAAA, with "Alias" toggled on) pointing to your ELB, CloudFront distribution, S3 website endpoint, or another Route 53 record. Alias records at the apex work correctly and incur no additional query charges.

Mistake #2: Alias to a deleted resource

You create an alias record pointing to an Application Load Balancer. Six months later, someone decommissions the service and deletes the ALB. The alias record still exists in Route 53, but it now points to nothing.

What happens next depends on the resource type. For deleted ELBs, the alias typically returns NXDOMAIN — the domain effectively stops resolving. For other resource types, you might get SERVFAIL or simply empty responses. Either way, your domain is broken.

This is Route 53's version of a dangling pointer. Unlike a regular CNAME (which just returns the target hostname and lets the client figure out it doesn't resolve), an alias that points to a dead resource actively breaks resolution at the authoritative level. The Route 53 console won't warn you — the record sits there looking perfectly normal until someone queries it.

The fix: Audit alias records periodically. Check that target resources still exist. If you're decommissioning infrastructure, include "delete associated DNS records" in your teardown checklist. Better yet, use automation that detects when alias targets no longer resolve and alerts you.

Mistake #3: Not using health checks with failover

Route 53 supports failover routing: you define a primary record and a secondary record, and Route 53 serves the secondary when the primary is unhealthy. Straightforward — except it only works if you attach a health check to the primary record.

Without a health check, Route 53 has no way to know the primary is down. The failover routing policy is configured, the secondary record exists, everything looks right in the console — but Route 53 always returns the primary because, as far as it knows, nothing is wrong. During an actual outage, traffic continues going to a dead endpoint.

Teams discover this during their first real incident, not during setup. The failover "worked" in the sense that it was configured, but it was never actually functional.

The fix: Always attach a health check to the primary record in a failover pair. Then test it — actually fail the primary and confirm Route 53 switches to the secondary. A failover configuration you haven't tested is a hypothesis, not a solution.

Mistake #4: Orphaned hosted zones

Route 53 lets you create multiple hosted zones for the same domain name. Each zone gets its own set of NS records. Only one zone is actually authoritative — the one whose NS records match what's configured at the registrar.

Here's how this goes wrong: you create a hosted zone for example.com in Account A and point your registrar's NS records to it. Later, during a migration or reorganization, someone creates a new hosted zone for example.com in Account B. They add records to the new zone, but the registrar still points to Account A's nameservers. All the records in Account B's zone are invisible to the internet.

The console shows everything working — records exist, they look correct, no errors. But queries never reach that zone because the delegation still points elsewhere. This can go undetected for weeks if the records in the old zone happen to still work.

The fix: Before creating records in a hosted zone, verify that the zone's NS records match what's configured at the registrar. Use dig NS example.com and compare against the NS records shown in the Route 53 hosted zone details. If they don't match, you're editing the wrong zone.

Mistake #5: Forgetting the trailing dot

In DNS, a fully qualified domain name ends with a dot: example.com. — the trailing dot indicates the root of the DNS hierarchy. The Route 53 console handles this automatically (you type api.example.com and it stores api.example.com.), so most people never think about it.

The problem surfaces when you use Terraform, the AWS CLI, or direct API calls. If you forget the trailing dot in a CNAME value, Route 53 may interpret it as a relative name and append the zone name, creating records like api.example.com.example.com. — a technically valid record that resolves to nothing useful.

This is especially insidious because the record appears in the console with the correct name. You have to look at the actual value to notice the double domain. And since it's a valid DNS name, Route 53 doesn't error — it happily serves the wrong answer.

The fix: When using infrastructure-as-code or the CLI, always use fully qualified domain names with trailing dots in record values. Validate your Terraform plans before applying — look for suspicious double-domain names in the records field.

Mistake #6: Wildcard records masking problems

A wildcard record (*.example.com) matches any subdomain that doesn't have an explicit record. Teams often add wildcards to catch all traffic — pointing *.example.com to a load balancer or a default web server.

The problem: wildcards silently take over when specific records disappear. Say you have an explicit A record for api.example.com pointing to your API server, and a wildcard pointing to your marketing site. If someone accidentally deletes the api.example.com record, the wildcard matches — and API traffic starts hitting your marketing site. No DNS error, no NXDOMAIN, just wrong content being served.

This makes problems hard to diagnose. The DNS is "working" (it resolves, it returns an IP), but the answer is wrong. Monitoring that only checks "does this name resolve?" won't catch it. You need monitoring that verifies the correct value is being returned.

The fix: Be deliberate about wildcards. If you use them, monitor your explicit records for unexpected deletion. Consider whether a wildcard is truly necessary or whether explicit records for each subdomain would be safer. If you must use wildcards, ensure your monitoring checks record values, not just resolution success.

Mistake #7: Cross-account confusion

Large organizations spread Route 53 zones across multiple AWS accounts — production in one account, staging in another, shared services in a third. When someone needs to make a DNS change, they need to know which account owns the zone for that domain.

The mistake: someone logs into the wrong account, finds a hosted zone with the right domain name (because there might be duplicate zones across accounts), makes their change, and it "works" in the console. But the domain's NS records at the registrar point to a different account's zone. The change is invisible to the internet.

In organizations with dozens of AWS accounts, this happens more often than you'd think. And it's not just a console problem — Terraform configurations that reference the wrong zone ID produce the same invisible result.

The fix: Maintain a clear mapping of domain → AWS account → hosted zone ID. Tag hosted zones with their purpose and environment. Before making changes, verify you're in the correct account by checking the zone's NS records against what's live on the internet.

Mistake #8: No audit trail for console changes

CloudTrail logs every Route 53 API call — including changes made through the console. But logging and monitoring are different things. Most teams have CloudTrail enabled (it's on by default for management events), but nobody is actively watching the Route 53 events.

Someone makes a "quick fix" in the console at 2am during an incident. It works, the incident is resolved, and nobody creates a ticket or updates documentation. Three months later, a different engineer looks at the zone and finds a record nobody can explain. The information exists in CloudTrail — but only if someone thinks to go looking for it.

CloudTrail is reactive: you search it after a problem occurs. It doesn't notify you when a change happens. It doesn't require approval before the change takes effect. It's an audit log, not a control mechanism.

The fix: Set up CloudTrail event notifications for Route 53 changes (via EventBridge → SNS or a Lambda). This turns your passive audit log into active notification. Better still, use a change control workflow that requires approval before changes apply — so you know about every change at the time it's proposed, not after the fact.

How change control prevents these

Each of these mistakes shares a common trait: they happen when DNS changes are made without a second pair of eyes, without automated validation, or without clear visibility into what's happening across accounts and zones.

When DNS changes go through a structured workflow:

None of these mistakes require exotic solutions. They require visibility, validation, and a workflow that makes the right thing easier than the wrong thing.