Route 53 — domains and DNS

Through Chapter 11 RDS we’ve got the backend’s compute / storage / DB domains in hand. This chapter is DNS, the point where users first meet our system. AWS’s managed DNS is Route 53, whose name comes from port 53 that DNS uses.

In this chapter we start from the big picture of DNS and lay out Route 53’s structure, record kinds (especially Alias), routing policies, and health checks at a glance. The Alias records we create here become the final piece that connects the load balancers of Chapter 13 ALB / NLB and ACM and the distributions of Chapter 14 CloudFront to a domain.

How DNS works — a 5-second recap #

DNS is the function that maps example.com to an IP. When the browser types example.com, the following happens.

1. browser: check `example.com` cache → none
2. OS: `/etc/hosts` → none
3. OS: the system DNS resolver (usually the router, or 1.1.1.1)
4. resolver: check cache → none → root → .com TLD → example.com's NS
5. example.com's NS = Route 53 → A record → 192.0.2.10
6. the response travels back, caching along the way

In this picture, point 5 — the authoritative DNS for the domain — is Route 53.

The meaning of TTL #

Each record has a TTL (Time To Live) attached. It sets how long resolvers and browsers cache it.

A long TTL means fast responses and low cost, but the time for a change to propagate worldwide is also long. At an operational cutover, it’s common to reduce the TTL ahead of time.

The structure of Route 53 #

Route 53’s components are as follows.

Domain registration vs Hosted Zone #

A frequently confused part. Where you bought the domain (the Registrar) and where you resolve DNS (the Hosted Zone) are separate.

Gabia (Registrar):
  example.com's NS = ns-1234.awsdns-56.com  ← set to the Route 53 NS
                       ns-2345.awsdns-67.org
                       ns-3456.awsdns-78.net
                       ns-4567.awsdns-89.co.uk

Route 53 Hosted Zone:
  example.com.
    NS    ns-1234... (auto-generated)
    SOA   ... (auto-generated)
    A     www → 192.0.2.10
    A     api → 198.51.100.20

The procedure to move a domain bought elsewhere to Route 53 is as follows.

1. Create a Public Hosted Zone in Route 53. Four NS are assigned automatically.
2. Enter those four NS in the NS field of the Registrar console.
3. Wait for propagation (a few minutes ~ 24 hours).
4. Verify with dig or nslookup.

The kinds of Hosted Zone #

Public Hosted Zone #

DNS resolvable from anywhere on the internet. The usual public DNS.

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference $(date +%s)

Private Hosted Zone #

DNS resolvable only inside a VPC. Used for internal service discovery.

internal domain: api.internal.example.com → 10.0.10.100 (app EC2)
                db.internal.example.com → RDS endpoint

Only EC2 in the VPC can resolve it, and it doesn’t resolve from the internet. It’s smooth for internal microservices.

Record kinds #

A / AAAA — a domain to an IP #

The most basic.

A     api.example.com.    300   192.0.2.10        (IPv4)
AAAA  api.example.com.    300   2001:db8::10      (IPv6)

CNAME — a domain to a domain #

An alias for another domain.

CNAME  www.example.com.    300   example.com.
CNAME  blog.example.com.   300   ghs.googlehosted.com.

The restrictions are as follows.

• A CNAME isn’t allowed on the root domain (example.com itself) (a limit of the DNS standard).
• If there’s a CNAME, it can’t coexist with other records (like MX, TXT).

When you want to send the root domain to an ALB or CloudFront, you can’t use a CNAME. This is where Alias comes in.

Alias — a Route 53-only construct #

Alias is a non-standard record that Route 53 created. At DNS response time it returns an IP like A / AAAA. It works around the limits of CNAME.

A   example.com.   ALIAS  d111111abcdef8.cloudfront.net    (CloudFront)
A   www.example.com. ALIAS my-alb-1234567890.elb.amazonaws.com  (ALB)
A   shop.example.com. ALIAS my-bucket.s3-website-ap-northeast-2.amazonaws.com (S3)

The characteristics are as follows.

• It can be used on the root domain too.
• It’s free (a CNAME is billed per query, but an Alias is free when it points to an AWS resource).
• Automatic IP refresh — ALB and CloudFront have dynamic IPs, and the Alias follows.

An Alias can point only to AWS resources (ALB, NLB, CloudFront, API Gateway, S3 website, another record in the same zone, etc.). For external domains you must use a CNAME.

MX — mail #

MX  example.com.   300   10 inbound-smtp.us-east-1.amazonaws.com.
                          20 inbound-smtp.us-east-2.amazonaws.com.

10 and 20 are priorities, where the smaller value takes precedence. They point to the SMTP hosts of SES / Google Workspace / Microsoft 365.

TXT — text #

Used for domain verification / SPF / DKIM, etc.

TXT   example.com.   300   "v=spf1 include:_spf.google.com ~all"
TXT   _dmarc.example.com. 300  "v=DMARC1; p=quarantine; rua=mailto:..."
TXT   _acme-challenge.example.com. 300  "lemonjuice123..." (Let's Encrypt verification)

NS / SOA — automatic #

Auto-generated when you create a Hosted Zone. Rarely touched.

CAA — certificate issuance authority #

Restricts which CA can issue a certificate for this domain.

CAA  example.com.  300  0 issue "amazon.com"

Note that when you issue a certificate with ACM (Chapter 13), it fails if CAA is blocking it.

Routing policies — the real charm of Route 53 #

You can respond to the same domain with multiple IPs under different conditions.

Simple Routing #

The simplest. Send one domain to one or several IPs. With several IPs it’s round-robin.

Weighted Routing — distribution by ratio #

Put a weight on each record to split by ratio. Useful for canary deployments.

A   api.example.com   ALIAS   alb-v1.elb...   weight=90
A   api.example.com   ALIAS   alb-v2.elb...   weight=10

Latency Routing — to the nearest region #

Run the same service in multiple regions and route users to the nearest region.

A   api.example.com   ALIAS   alb-seoul...   region=ap-northeast-2
A   api.example.com   ALIAS   alb-tokyo...   region=ap-northeast-1
A   api.example.com   ALIAS   alb-virginia...region=us-east-1

Korean users go to Seoul, Japanese users to Tokyo, and US users to Virginia.

Failover Routing — automatic failover #

Set Primary and Secondary as two targets, and when the Primary fails the health check, send to the Secondary.

A   api.example.com   ALIAS   alb-prod-seoul...   PRIMARY   health-check=HC1
A   api.example.com   ALIAS   alb-dr-tokyo...     SECONDARY

Geolocation Routing — by country / continent #

Route by the user’s geographic location. Used for compliance or content differences.

A   api.example.com   ALIAS   alb-kr...   geolocation=KR (Korea)
A   api.example.com   ALIAS   alb-jp...   geolocation=JP (Japan)
A   api.example.com   ALIAS   alb-default... geolocation=DEFAULT (others)

Geoproximity Routing #

Adds a bias to geography. The internal AWS algorithm is more complex. Rarely touched.

Multivalue Answer Routing #

Responds with several IPs at random. Combined with a health check, it returns only live IPs. It’s simple client-side load distribution.

A policy decision guide #

just one → Simple
want to split deployment ratio → Weighted
the nearest of several regions → Latency
for DR / backup → Failover
country-level compliance → Geolocation
DNS-level load distribution → Multivalue

Health Check #

The core companion of routing policies. It checks every 30 seconds whether an endpoint is alive.

aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "ResourcePath": "/health",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

The kinds are as follows.

• HTTP / HTTPS / TCP — check an endpoint directly.
• Calculated — an AND / OR combination of other health checks.
• CloudWatch Alarm based — judge by an alarm’s state.

A Health Check is both the automatic-switch trigger of Failover routing and the live-IP filter of Multivalue routing. It can be used standalone, but usually it’s combined with a routing policy.

Domain operations — commonly used patterns #

Main site + subdomains #

A      example.com.        ALIAS   www.example.com.    (root → www)
A      www.example.com.    ALIAS   d111...cloudfront.net
A      api.example.com.    ALIAS   alb-prod...elb.amazonaws.com
A      app.example.com.    ALIAS   d222...cloudfront.net
TXT    _dmarc.example.com. "v=DMARC1; p=reject; ..."
MX     example.com.        10 inbound-smtp.ses-us-east-1.amazonaws.com.

Separation by environment #

api.dev.example.com       ← dev environment ALB
api.staging.example.com   ← staging
api.example.com           ← prod

Or you can place dev.example.com in a separate Hosted Zone. Delegating authority becomes clean.

The Apex (root) domain’s ALB / S3 #

When you can’t use a CNAME, use an Alias. The ALB’s zone is matched automatically (a dropdown in the console).

Cost #

A small site is around $1 ~ 2 a month.

Common pitfalls #

• Touching only Route 53 without changing the NS — If you created a Hosted Zone but the Registrar’s NS are still the old values, no change is reflected at all. Verify with dig NS example.com +short that you entered the four NS at the Registrar.
• Attempting an Apex CNAME — example.com CNAME myapp.heroku.com is rejected. An Alias points only to AWS resources. If an external service needs to be on the root domain, either that service provides an ALIAS-like feature (e.g., CloudFlare CNAME flattening) or you use a separate redirector pattern (S3 redirect from Apex to www).
• TTL too long, so cutover becomes slow — Just before an operational cutover (e.g., replacing an ALB), lower the TTL to around 60 seconds, and raise it again after it stabilizes. If you don’t lower it ahead of time, the old IP may be cached for 24 hours.
• Health Check false positive — If the check path requires authentication, it always returns 401 and becomes unhealthy. Place a public endpoint like /health.
• Failover but no health check attached — If the PRIMARY record has no health check, automatic failover doesn’t work. Missing the console’s “evaluate target health” option is a common mistake.
• Turning on DNSSEC and forgetting — If you forget DNSSEC’s KSK / ZSK rotation, domain resolution itself fails. When you turn it on, do so carefully with automation.
• A Private Hosted Zone not resolving in the VPC — If the VPC’s enableDnsHostnames / enableDnsSupport are off, the Private Hosted Zone doesn’t resolve. Check that both are true.
• A syntax mistake in MX priority — In MX 10 mail.example.com., omitting the 10 item breaks resolution itself.

Exercises #

1. Assume you bought your domain from another registrar, and write down the four steps to move its DNS to Route 53 without looking at §“Domain registration vs Hosted Zone”. Mark which step, if omitted, becomes the first item in §“Common pitfalls”.
2. You want to connect the root domain example.com to a CloudFront distribution. Explain in one paragraph why a CNAME doesn’t work and why an Alias does, based on §“CNAME” and §“Alias”, and add one sentence on how that Alias points to the Chapter 14 CloudFront distribution.
3. You have the same service in Seoul and Tokyo and want to fail over to the other region when one region dies. Write down which of the seven §“Routing policies” you should choose, and why §“Health Check” is also needed alongside it.

In short: Route 53 is managed DNS, where the place you bought the domain (the Registrar) and the place you resolve DNS (the Hosted Zone) are separate, and pointing the Registrar’s NS at the Route 53 NS is the starting point. Alias is a Route 53-only record that works even on the root domain and is free when it points to an AWS resource. Of the seven routing policies, Failover and Multivalue use a Health Check as the automatic-switch trigger.

Next chapter #

We’ve got the big picture of DNS in hand. Next, Chapter 13 ALB / NLB and ACM carries into the load balancers that domain points to and HTTPS. We’ll lay out the difference between ALB / NLB / GWLB, the flow of Listener / Target Group / Health Check, ACM’s certificate issuance and automatic renewal, and the operational patterns of HTTPS.