DNS and Route 53: Your Site's Address

The load balancer in our application from part seven has a name like web-alb-1234567890.eu-central-1.elb.amazonaws.com. Nobody is going to type that. Visitors want shop.example.com, and what connects the two is DNS.

This section is about the visitor's path to your application: the name in this part, speed in the next, then the private network everything lives in.

How DNS works #

DNS is the internet's phone book: you ask with a name and it answers with an address. No single server knows everything, so the answer comes through a chain:

1. Your browser asks the resolver, usually from your internet provider or a public service such as 1.1.1.1.
2. The resolver asks the root servers, which point it to the .com servers.
3. The .com servers point it to the domain's name servers.
4. The domain's name servers give the final answer.
5. The resolver returns the address to the browser and keeps it for the TTL, so the next person asking gets an instant answer.

These are the terms you'll come across:

Route 53 #

Route 53 is AWS's DNS service, named after DNS's port 53. It has three jobs: holding your domain's records and answering for them, registering domains, and watching your application's health and directing visitors accordingly. AWS commits to 100% availability for it.

Hosted zones #

Each costs about half a dollar a month, plus a small charge for queries.

Record types #

CNAME or Alias? #

Here's a common problem: a CNAME can't be used on the root domain example.com, yet you want it to point at your load balancer. The solution is an Alias, a special type in Route 53:

The rule is simple: if the target is on AWS, use an Alias. Note that it can't point to an EC2 server's DNS name.

Choosing a TTL #

• A long TTL: fewer queries and lower cost, but any change takes time to spread.
• A short TTL: changes spread quickly, but queries increase.

Routing policies #

"Routing" here doesn't mean traffic passes through Route 53. It only chooses which answer to give, and the visitor then connects directly to that address.

Health checks #

For Failover and the others to work, Route 53 has to know who's healthy:

The checkers come from the internet, so they can't reach a server in a private network, and your security group has to allow their ranges if you're checking a public target.

A domain bought elsewhere #

Buying a domain and managing its records are two separate things. If you bought yours from another company and want Route 53 to answer for it:

1. Create a public hosted zone with the domain's name.
2. Copy the four name servers from its NS record.
3. Paste them into the domain's settings at the company you bought it from.

Once the change spreads, Route 53 is the one answering.

If you have a network in your office, you can connect its DNS with AWS through Resolver endpoints: inbound lets your network ask about AWS's private names, and outbound lets AWS ask about your network's names. This needs a connection between the two networks, which is the subject of part fourteen.

Hands-on: weighted routing without buying a domain #

A private hosted zone lets you try all this without a real domain. We'll use your web-1 server from part three, inside the default network. From CloudShell, create the private domain:

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true \
  --query "Vpcs[0].VpcId" --output text)

ZONE_ID=$(aws route53 create-hosted-zone --name series.internal \
  --caller-reference "demo-$(date +%s)" \
  --vpc VPCRegion=$AWS_REGION,VPCId=$VPC_ID \
  --query HostedZone.Id --output text)

Now add two records for the same name, 80% for the old version and 20% for the new. The addresses are made up, because DNS only answers and doesn't connect to them:

CHANGES='{"Changes":[
  {"Action":"CREATE","ResourceRecordSet":{"Name":"app.series.internal","Type":"A","TTL":5,
    "SetIdentifier":"old","Weight":80,"ResourceRecords":[{"Value":"10.0.0.80"}]}},
  {"Action":"CREATE","ResourceRecordSet":{"Name":"app.series.internal","Type":"A","TTL":5,
    "SetIdentifier":"new","Weight":20,"ResourceRecords":[{"Value":"10.0.0.20"}]}}
]}'

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" --change-batch "$CHANGES"

Sign in to the server through EC2 Instance Connect and ask 20 times. It takes two minutes, because we wait for the TTL to expire each time:

sudo dnf install -y bind-utils

for i in $(seq 1 20); do
  dig +short app.series.internal
  sleep 6
done | sort | uniq -c

You'll see a split close to 16 and 4. Try dig +trace aws.amazon.com as well, and you'll see the chain from the diagram step by step.

If you have a domain, add an A record of the Alias kind pointing at your load balancer, and your site now has your name.

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" --change-batch "${CHANGES//CREATE/DELETE}"

aws route53 delete-hosted-zone --id "$ZONE_ID"

Summary #

• DNS turns a name into an address through a chain, and the answer is kept for the TTL.
• Route 53 holds your records, and a hosted zone can be public or private.
• If the target is on AWS, use an Alias, which works on the root domain.
• Routing policies only choose the answer; traffic doesn't pass through them.
• Health checks are what make Failover work.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

Your site now has a name, but its server is still in one place and the distant visitor is still waiting. In part twelve we bring it closer with CloudFront and Global Accelerator.