How to Set Up Route 53 DNS for Your Domain on AWS

Amazon Route 53 is AWS's authoritative DNS service, and it's one of the most reliable ways to host DNS for a production domain — but the setup process has enough moving parts that misconfiguring one step leaves you chasing ghost propagation delays. This tutorial covers the entire flow: creating a hosted zone, adding the right records, delegating your domain at the registrar, verifying with CLI tools, and locking everything down with DNSSEC. Intermediate level assumed — you know what an A record is, you've opened the AWS console before.

What Route 53 Actually Does

Route 53 serves two distinct functions that often get conflated. First, it's a domain registrar — you can buy and manage domain registrations directly inside Route 53. Second, and far more commonly used, it's an authoritative DNS service — you point your domain's nameservers (registered anywhere) at Route 53, and it answers DNS queries for that domain worldwide.

This tutorial focuses on the authoritative DNS role, which is what you need when migrating an existing domain to AWS or hosting a new project behind EC2, CloudFront, or an Application Load Balancer.

Route 53 runs on a global anycast network. Each hosted zone gets four nameservers spread across all AWS regions, which drives query latency below 5 ms from most locations globally. It's one of the only AWS services with a 100% uptime SLA — that's not a typo.

Core Concepts Before You Touch the Console

Hosted Zones

A hosted zone is a container for DNS records for a single domain (e.g., example.com). Every hosted zone costs $0.50/month from the moment it's created — even with zero traffic. Public hosted zones answer queries from the internet. Private hosted zones answer only within a specified VPC. This tutorial covers public zones only.

When you create a hosted zone, Route 53 auto-generates two records: four NS records (the nameservers assigned to your zone) and one SOA record. Those nameservers are unique to your hosted zone — they are not shared across accounts, not static, and not the same as the ones in any colleague's zone. This is a frequent source of confusion when people copy nameserver values from a screenshot.

Record Types You Will Actually Use

• A — maps a hostname to an IPv4 address
• AAAA — maps a hostname to an IPv6 address
• CNAME — aliases one hostname to another; cannot be used at the zone apex
• ALIAS — Route 53 proprietary; works like CNAME but is allowed at the apex and resolves to AWS resource IPs internally
• MX — mail routing priority and destination
• TXT — SPF, DKIM, domain verification tokens
• NS — nameserver delegation (auto-created; do not delete)
• CAA — restricts which CAs can issue SSL certs for your domain
• DS — DNSSEC delegation signer, submitted to your registrar

The ALIAS record is Route 53's most useful proprietary feature. Use it whenever you would normally CNAME the apex — pointing example.com directly to a CloudFront distribution or ALB without the RFC-violating CNAME-at-apex problem. Queries to ALIAS targets that are AWS resources are also free — Route 53 does not charge for them.

Step 1: Create a Public Hosted Zone

In the AWS console, navigate to Route 53 → Hosted zones → Create hosted zone. Enter your domain name exactly as registered — example.com, no trailing dot, no www prefix. Leave the type as Public hosted zone. Click Create hosted zone.

Route 53 immediately creates an NS record with four nameservers and an SOA record. Copy those four NS values now. They look like this:

Note the four different TLDs (.com, .net, .org, .co.uk). This is intentional — a TLD-level outage cannot take out all four servers simultaneously. You will need these values in Step 3.

Step 2: Add DNS Records

Inside your hosted zone, click Create record. The console offers a simple form and a wizard mode — use the simple form unless you need routing policies.

Pointing the Apex to a Static IP

To point your bare domain to a single IPv4 address (an EC2 instance, a Lightsail static IP, etc.):

• Record name: leave blank (targets the apex, example.com)
• Record type: A
• Value: your server's public IP, e.g., 203.0.113.45
• TTL: 300 during testing; raise to 3600 once stable

Pointing to CloudFront or an ALB via ALIAS

Select record type A, toggle on Alias, then pick your target from the dropdown: CloudFront distribution, Application Load Balancer, API Gateway, Elastic Beanstalk, S3 website endpoint, and more. Route 53 resolves the target's current IPs internally and returns them to clients. You pay nothing for the queries.

Adding www as a CNAME

• Record name: www
• Record type: CNAME
• Value: example.com or your CloudFront hostname
• TTL: 300

MX Records for Email

Add MX records at the apex. For Google Workspace, the values are:

TXT Records for SPF and Domain Verification

TXT record values must be wrapped in double quotes in the Route 53 console. If your SPF record is v=spf1 include:_spf.google.com ~all, enter it as:

If you need multiple TXT values at the same name — SPF plus a Google site-verification token, for example — put them in the same record, one value per line. Do not create two separate TXT records with the same name; Route 53 will reject the second entry.

Step 3: Delegate Your Domain to Route 53

This is the step most tutorials skip past too quickly. You must log into wherever your domain is registered — not where it was previously hosted — and replace the current nameservers with the four Route 53 NS values from Step 1.

Common registrar paths:

• GoDaddy: My Products → DNS → Nameservers → Change → Enter My Own Nameservers
• Namecheap: Domain List → Manage → Nameservers → Custom DNS
• Google Domains / Squarespace: DNS → Nameservers → Use Custom Nameservers
• Cloudflare Registrar: Zone → DNS → Advanced → Custom Nameservers
• Route 53 itself: Registered domains → [your domain] → Name servers → Edit name servers

Enter all four nameservers exactly as shown in Route 53. Most registrar UIs do not want a trailing dot; add it only if the UI specifically asks for fully-qualified names. Save the changes and wait — NS delegation propagates via the TLD registry (.com, .ca, .net, etc.), which can take anywhere from a few minutes to 48 hours at the outer limit. Two hours is typical.

Step 4: Verify with CLI Tools

Never trust the console alone. Use command-line tools to confirm what the internet actually sees.

Check Nameserver Delegation

This should return your four Route 53 nameservers. If it returns your old host's nameservers, delegation has not propagated yet — or you haven't updated the registrar.

Query Route 53 Directly (Bypass Local Cache)

Replace the nameserver with one of your actual Route 53 NS values. This bypasses your ISP's resolver and hits Route 53 directly. If this returns the correct IP, the record is correct — propagation to public resolvers is a separate, time-bound concern.

Windows (nslookup)

Linux with systemd-resolved

On systemd-resolved systems, check your current upstream resolver with resolvectl status. If you're running DNS-over-TLS locally, you may be hitting a different upstream than expected — query a known public resolver directly to isolate.

Verify a DKIM Selector or CAA Record

For DKIM, the selector is part of the record name. Query it like this:

Use the DNS Lookup tool to run live queries against any record type without memorizing dig flags — useful for checking DKIM selectors, CAA records, and TXT values on the fly.

Routing Policies: Beyond Basic Records

Route 53 supports several routing policies that go far beyond what basic authoritative DNS offers. Worth knowing even if you don't need them immediately.

• Simple — one or more IPs; round-robins if multiple values returned
• Weighted — splits traffic between endpoints by percentage; use for blue/green or canary deploys
• Latency-based — routes users to the AWS region with the lowest measured latency for them
• Failover — primary/secondary with health check; Route 53 automatically switches if the primary endpoint fails
• Geolocation — routes by country or continent
• Geoproximity — routes by physical proximity to a location, adjustable with a bias value
• IP-based — routes by source IP CIDR; added 2022, useful for ISP-tier differentiation
• Multivalue answer — returns up to eight healthy IPs, acts as a client-side load balancer

Failover and latency-based routing require associating records with Route 53 health checks, which monitor endpoints (HTTP, HTTPS, or TCP) from multiple AWS regions on a configurable interval. Health checks start at $0.50/month each.

DNSSEC on Route 53 in 2026

Route 53 has supported DNSSEC signing for public hosted zones since late 2020. As of 2026, enabling it is the right call for any domain where DNS hijacking or cache poisoning is a real threat — financial services, healthcare, e-commerce, government.

To enable: go to your hosted zone → DNSSEC signing → Enable DNSSEC signing. Route 53 creates a Key Signing Key (KSK) in AWS KMS. After enabling, Route 53 provides a DS record value that you must submit to your registrar — not add inside Route 53 itself. That DS record establishes the chain of trust from the TLD down to your zone.

The most common DNSSEC mistake: people add the DS record as a new record inside their Route 53 hosted zone. That does nothing. The DS record belongs at the parent zone — your registrar submits it to the TLD registry on your behalf. GoDaddy, Namecheap, and Route 53 Registrar all support DS record submission from their management panels.

If you enable DNSSEC signing in Route 53 but don't submit the DS record at the registrar, resolution continues normally and nothing breaks — DNSSEC validation isn't enforced until the DS record is published at the TLD. Only after that does the chain of trust activate, and DNSSEC-validating resolvers will reject tampered responses for your domain.

For the full DNSSEC protocol specification, see RFC 4035 at the IETF, which defines how validators traverse the chain of trust from root to zone.

IPv6 and AAAA Records

If your infrastructure supports IPv6 — and in 2026, most AWS load balancers and CloudFront distributions do — add AAAA records alongside every A record. EC2 instances need an IPv6 address explicitly assigned (VPC → Subnets → Enable auto-assign IPv6 address). ALBs and CloudFront serve IPv6 by default on their dualstack endpoints.

For a CloudFront distribution, the ALIAS record for IPv6 targets the dualstack hostname:

Many Canadian and European ISPs route mobile traffic over IPv6-first networks. Without AAAA records, those users fall back to IPv4 with a measurable latency penalty. The fix is cheap — add the AAAA records alongside every A record you publish.

Common Misdiagnoses

Records not propagating — but delegation was never done

The most common issue, by a wide margin. People add records in Route 53 but never update the nameservers at their registrar. Route 53 cannot answer queries for a domain unless your registrar has delegated the NS records to Route 53. Run dig NS example.com to confirm what nameservers the internet currently sees. If it returns your old host's nameservers, the registrar update hasn't happened — no amount of waiting will fix it.

Using stale nameservers from a deleted hosted zone

If you've deleted and recreated a hosted zone (or have multiple zones for the same domain in the same account), the nameservers change with each creation. Using NS values from the wrong or deleted zone is a silent misconfiguration — Route 53 will not warn you. Always copy NS values directly from the currently active hosted zone in the console.

ALIAS vs. CNAME confusion at the apex

A CNAME record at the zone apex (example.com, not www.example.com) violates DNS standards (RFC 1034). Route 53 will refuse to create it. If you migrated from a provider that silently accepted a CNAME at the apex via their own flattening logic, you'll need to switch to an ALIAS record in Route 53. The ALIAS record is the correct mechanism — it behaves like a CNAME but is resolved server-side by Route 53 before the answer leaves.

TTL set too high before a planned migration

If an A record has a TTL of 86400 (24 hours) and you urgently need to change the target IP, you're stuck waiting for the cache to expire on every resolver that has already cached the old value. Best practice: lower the TTL to 300 at least 24 hours before any planned cutover. Once the migration is stable, raise it back to 3600. Route 53 handles high query rates well — low TTLs won't stress the service.

Multiple TXT records with the same name

Route 53 allows only one TXT record per name. If you try to create a second TXT record at the same name (e.g., a second TXT at the apex for a verification token alongside your SPF), Route 53 will reject it. Combine all values into a single TXT record, one quoted string per line in the console. This is correct per RFC and the fix for most "verification token not found" errors after adding SPF or DKIM.

How to Confirm Everything Is Working

1. Run dig NS example.com +short — all four Route 53 nameservers should appear.
2. Run dig A example.com @ns-123.awsdns-12.com +short — the correct IP or ALIAS target should resolve directly from Route 53.
3. Run dig A example.com @8.8.8.8 +short — Google's public resolver should return the correct IP, confirming propagation.
4. Run dig MX example.com +short and dig TXT example.com +short to verify email and verification records.
5. If DNSSEC is enabled: dig A example.com @8.8.8.8 +dnssec — look for an RRSIG record alongside the A record in the answer section.
6. Test from a second network (mobile data, a VPN exit) to rule out a locally cached stale response.
7. Check email deliverability with an SPF/DKIM validator after MX records are live — a misconfigured TXT record won't show up in DNS lookups but will cause mail rejection.

Cost and Billing

Route 53 charges $0.50/month per hosted zone for the first 25 zones ($0.10/zone after that), plus $0.40 per million standard queries and $0.60 per million for latency-based, weighted, geolocation, or failover queries. Health checks start at $0.50/month each. For a typical small business site with one hosted zone and a few records, the monthly Route 53 bill is under $2. Queries to ALIAS records pointing at AWS resources (CloudFront, ALB, S3, API Gateway) are free — Route 53 does not count them toward your query total.

Preventing Future Issues

• Tag hosted zones with environment, team, and project — Route 53 tags feed into AWS Cost Explorer and IAM condition keys for access control.
• Protect NS and SOA records via IAM: create an SCP or resource-based policy that denies deletion of NS and SOA records. Accidental NS deletion breaks the entire domain with no automatic rollback.
• Export zone backups before bulk changes: aws route53 list-resource-record-sets --hosted-zone-id /hostedzone/ZXXXXXXX saves the full zone as JSON. Keep a copy before any scripted import or migration.
• Use infrastructure-as-code for anything beyond a single manually managed site. Terraform's aws_route53_record resource or AWS CDK keeps DNS changes in version control, auditable, and repeatable across environments.
• Enable query logging (Route 53 → hosted zone → Configure query logging → CloudWatch Logs) if you need visibility into what's hitting your zone — useful for debugging resolution failures and detecting DNS reconnaissance activity.
• Lower TTLs before planned cutovers and raise them again afterward. A forgotten 86400-second TTL is the most common cause of prolonged post-migration disruption.