*Understanding Amazon Route 53 Record Types

Summary

In this lab I worked with DNS records in Amazon Route 53. I launched an Amazon Linux EC2 instance, installed the Apache web server, and published a simple web page. I created a public hosted zone and added an A record named learn that pointed to the instance's public IP. I then created a CNAME record named test that pointed to learn.YOUR_DOMAIN. I didn't own a registered domain, so instead of opening the names in a browser, I verified both records by asking Route 53 directly, with the console's Test record tool and with nslookup against the hosted zone's own name servers. Finally, I reviewed the purpose of the other common record types: AAAA, MX, TXT, PTR, SRV, and SPF.

Lab Environment

DNS records created:

Route 53 is a global service, so the hosted zone and its records weren't tied to Canada (Central). Only the EC2 instance lived in that region.

Part 1: Creating the Hosted Zone

I opened the Route 53 console, went to Hosted zones, and clicked Create hosted zone. I entered YOUR_DOMAIN as the Domain name, chose Public hosted zone, and clicked Create hosted zone. A public hosted zone holds the DNS records that answer lookups for a domain.

Route 53 created two records in the zone automatically:

• NS: the four Route 53 name servers that hold this zone's records, such as ns-123.awsdns-45.com.
• SOA: basic information about the zone itself.

I left both alone, and noted one of the NS values for testing later.

I didn't register the domain, so this zone existed only inside Route 53. Normally, a domain's registrar tells the internet which name servers to ask about it. Since no registrar pointed anywhere at these four name servers, the rest of the internet would never send lookups for YOUR_DOMAIN to my zone. The records would still work, but only when I asked Route 53's name servers directly.

Part 2: Launching and Configuring the Web Server

1. Launched the instance

In the EC2 console, I launched an Amazon Linux instance in a public subnet in ca-central-1a, with Auto-assign public IP enabled and an existing key pair. Its security group allowed:

I waited until the instance showed Running.

2. Connected over SSH

From Command Prompt, in the folder with my key:

ssh -i KEY_NAME.pem ec2-user@EC2_PUBLIC_IP

3. Installed Apache

sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpd

start launched the web server right away, and enable made it start automatically whenever the instance rebooted.

4. Created the web page

I wrote a simple HTML page to Apache's web folder:

sudo tee /var/www/html/index.html > /dev/null <<'EOF'
<!DOCTYPE html>
<html>
<head>
  <title>Route 53 Record Types Demo</title>
</head>
<body>
  <h1>Route 53 Record Types Lab</h1>
  <p>This page is served from an EC2 web server.</p>
</body>
</html>
EOF

Then I gave the file to Apache's user and made it readable:

sudo chown apache:apache /var/www/html/index.html
sudo chmod 644 /var/www/html/index.html

5. Verified the web server

On the instance:

curl -s localhost

It printed the HTML of my page. Then I opened http://EC2_PUBLIC_IP in my browser and the page loaded, confirming the server was reachable from the internet before I added any DNS.

Part 3: Creating the A Record

Back in the hosted zone, I clicked Create record and entered:

I clicked Create records. The full name became learn.YOUR_DOMAIN, because the record name is added in front of the hosted zone's domain.

The TTL (time to live) is how long, in seconds, other DNS servers and browsers can remember the answer before asking Route 53 again. With 300 seconds, a change to the record can take up to 5 minutes to reach everyone.

Part 4: Verifying the A Record

Without a registered domain, opening http://learn.YOUR_DOMAIN in a browser wouldn't work, because my computer's DNS would never find my hosted zone. So I checked the record against Route 53 directly, in two ways.

1. Test record in the console

In the hosted zone, I clicked Test record, entered learn as the Record name, chose A as the Type, and clicked Get response. Route 53 answered with:

NOERROR meant the name existed and Route 53 returned an answer.

2. nslookup against the zone's name server

From my computer's Command Prompt, I asked one of the zone's own name servers instead of my usual DNS server:

nslookup learn.YOUR_DOMAIN ns-123.awsdns-45.com

using one of the actual NS values from the hosted zone. It returned the instance's public IP, the same answer as the console.

Adding the name server at the end of nslookup is what made this work. Without it, my computer would ask its normal DNS server, which would have no idea where to find YOUR_DOMAIN and would answer that the name doesn't exist.

Part 5: Creating the CNAME Record

I clicked Create record again and entered:

I clicked Create records.

A CNAME doesn't point to an IP address. It says "this name is another name for that name." When someone looks up test.YOUR_DOMAIN, DNS answers with learn.YOUR_DOMAIN, then looks that up to get the IP.

Part 6: Verifying the CNAME Record

1. Test record in the console

In Test record, I entered test as the Record name, chose CNAME as the Type, and clicked Get response. Route 53 answered with learn.YOUR_DOMAIN and a response code of NOERROR.

The answer was a name, not an IP address, because a CNAME only says which other name to look up next.

2. nslookup against the zone's name server

nslookup test.YOUR_DOMAIN ns-123.awsdns-45.com

The result showed test.YOUR_DOMAIN as an alias (canonical name) of learn.YOUR_DOMAIN, followed by the instance's public IP. Because both names were in the same hosted zone, Route 53 followed the CNAME to the A record and returned both answers together.

Both names led to the same IP, so with a registered domain, both would open the same website. If the instance's IP ever changed, I'd only need to update the learn A record, and test would follow it automatically.

A CNAME isn't a redirect. In a browser, the address bar would keep showing test.YOUR_DOMAIN. DNS just follows the CNAME behind the scenes to find the IP, and the web server answers for whichever name was used.

Part 7: Reviewing Other Record Types

What I Learned

• A domain only resolves on the internet when its registrar points to the hosted zone's name servers. Without that link, a public hosted zone's records still work, but only when Route 53's name servers are asked directly, with Test record or nslookup NAME NAME_SERVER.
• A hosted zone holds all the DNS records for a domain. A public hosted zone answers lookups from the internet, and a private one answers only inside linked VPCs.
• An A record points a name directly at an IPv4 address, which is the simplest way to put a website on a domain.
• A CNAME points a name at another name, not an IP. Updating the target record updates every CNAME pointing to it.
• A CNAME can't be used on the root domain (YOUR_DOMAIN itself), and a name with a CNAME can't have any other records. Route 53's Alias records solve this for AWS resources like load balancers and CloudFront.
• A CNAME is not a redirect. The address bar keeps the name the user typed, and the website just needs to respond to it. Apache's default setup answers for any name, which is why test.YOUR_DOMAIN worked without changing the server.
• TTL controls how long other DNS servers cache an answer. A shorter TTL means changes spread faster, at the cost of more DNS queries.
• Route 53 is global, so its records aren't tied to a region, even though the resources they point to are.
• Pointing an A record at an instance's auto-assigned public IP is fragile: the IP changes if the instance is stopped and started, and the record would point to the wrong address. An Elastic IP, or an Alias record pointing to a load balancer, keeps the name working.

Notes

• The SPF record type still exists in Route 53, but it's deprecated in the DNS standards. SPF policies are now published as TXT records instead.
• PTR records for EC2 public IPs aren't created in your own hosted zone. AWS owns those IP ranges, so reverse DNS for an Elastic IP is set through EC2.
• The provided index.html was originally titled "CloudFront Origin Group Demo", reused from another lab. I used a simpler page with a title matching this lab, which works the same way.

Cleanup

The running instance and its public IPv4 address were billed by the hour. The hosted zone is billed monthly, and leaving records that point at a released IP is a bad habit, since that IP might later belong to someone else. I deleted everything from this lab:

1. Deleted the DNS records

In the hosted zone, I selected the test CNAME record and the learn A record, clicked Delete records, and confirmed. The NS and SOA records can't be deleted on their own; they're removed along with the zone.

2. Terminated the instance

In the EC2 console, I selected the instance and clicked Instance state → Terminate (delete) instance. This also deleted its root volume and released its public IP.

3. Deleted the security group

Once the instance showed Terminated, I deleted the security group created for it.

4. Deleted the hosted zone

The hosted zone was created just for this lab, so I deleted it too. With only the NS and SOA records left, I selected the zone in Hosted zones, clicked Delete, and confirmed. A hosted zone can't be deleted while it still contains other records, which is why the A and CNAME records had to go first.

A hosted zone is billed monthly, but AWS doesn't charge for one that's deleted within 12 hours of being created, so deleting it right after the lab meant it cost nothing.