Route 53 DNS Foundations

Create a Route 53 hosted zone, configure DNS records, and master the alias vs CNAME distinction.

Introduction

30 Second Summary

Every time you type a website address into your browser, something invisible translates that friendly name into a number that computers understand. That system is called DNS, and it's how every website on the internet gets found.

In this project, you will use Route 53 to set up a DNS zone, create different types of DNS records, and connect your zone to a live website hosted on S3. By the end, you'll understand the difference between alias records and CNAME records, one of the most common topics on the AWS certification exam.

What You'll Build

By the end, you will test your DNS setup from the terminal, see how alias records give back IP addresses while CNAME records give back website names, and know exactly when to use each one.

By the end of this project, you'll have:

  • A working DNS zone with multiple record types (A, CNAME, TXT, and MX) that you created yourself and tested from the terminal.
  • A clear understanding of why alias records exist and when you must use them instead of CNAME records at the top level of your domain.
  • Experience creating different DNS record types so you can explain what each one does and when to use it.
  • Secret Mission: Configure a weighted routing policy to distribute traffic across two S3 endpoints and observe the load-balancing behavior.

Are there any prerequisites?

You need an AWS account with console access and some familiarity with S3. This project costs approximately $0.50 for the hosted zone (free if deleted within 12 hours) plus negligible S3 storage charges.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters. You'll be spending real money on a domain name in the next step, so take a moment to decide what domain you want to register and what your one-page website will say.

Create a Hosted Zone and Explore Your Hosted Zone

Create a Hosted Zone and Explore DNS Fundamentals

Every website starts with a domain name. Without one, users would need to remember raw IP addresses to reach your site. The system that translates domain names into addresses is DNS.

In this step, you will create a public hosted zone in Route 53 and explore the NS and SOA records that AWS assigns automatically. You do not need to buy a domain. You will query Route 53's name servers directly to verify your records work.

In this step, get ready to:
  • Create a public hosted zone in Route 53.
  • Examine the auto-created NS and SOA records.
  • Verify your NS records from the terminal using nslookup.
Create a public hosted zone in Route 53

A hosted zone is a container that holds all the DNS records for one domain. You will create one for a practice domain name. Since you are not buying this domain, it won't work in a browser. But you can test it directly by asking Route 53's servers, which shows you exactly how DNS works.

  • Open the AWS Management Console and navigate to the Route 53 service.
  • In the left navigation pane, click Hosted zones.
  • Click Create hosted zone.
  • In the Domain name field, enter a practice domain name (e.g. nextwork-dns-lab.com).
  • For Type, select Public hosted zone.
  • Click Create hosted zone.

Why can I use a domain I don't own?

Route 53 lets you create a hosted zone for any domain name. It assigns name servers and stores your records. The zone won't resolve publicly unless you also register the domain and delegate it to these name servers, but you can query Route 53's name servers directly to test your records.

This approach gives you the same hands-on DNS experience without the cost of domain registration.

Examine the auto-created records

Route 53 automatically created two records when you made the hosted zone. These are essential for DNS to work.

  • Find the NS record. It contains four name server values, each starting with ns- and ending in a domain like awsdns-XX.com, awsdns-XX.net, awsdns-XX.org, or awsdns-XX.co.uk.
  • Find the SOA record. This Start of Authority record identifies the primary name server for the zone and contains serial number, refresh, retry, and expiry timers.

What do NS and SOA records do?

NS (Name Server) records are like an address book entry. They tell the internet which servers know the answers for your domain. When someone looks up your domain, these records point them to the right place.

The SOA (Start of Authority) record identifies the main server in charge of your domain and keeps track of changes. Think of NS records as the phone book listing, and SOA as the ID card for your zone.

Verify your NS records with nslookup

You have seen your name servers in the Route 53 console. Now you will query one of those name servers directly from your terminal to confirm it responds.

  • Open your terminal. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Terminal (macOS) or cmd (Windows) and press Enter to open it.

Copy one of your four NS values from the Route 53 console. You will use it to query your hosted zone directly.

  • Query the SOA record for your domain by running this command:
nslookup -type=SOA [[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

What does this command do?

  • nslookup is a tool that lets you look up DNS records. It works on macOS, Windows, and Linux.
  • -type=SOA tells it you want to look up the Start of Authority record specifically.
  • The domain name is what you are looking up.
  • The last argument is which server to ask. By asking Route 53's server directly, you skip the normal internet lookup process and go straight to the source.

You should see the SOA record come back with your hosted zone's main server name and a serial number. This confirms your hosted zone is working and answering questions.

Not seeing a response?

Make sure you copied the full name server value from the NS record (e.g. ns-1234.awsdns-12.org). The name server must be one of the four assigned to your hosted zone.

Help me troubleshoot why nslookup is not returning my Route 53 SOA record.

Your hosted zone is live and responding to queries. Next up, you will create a static website on S3 to give your DNS records something to point at.

Host a Static Website on S3

You have a hosted zone with name servers, but no records pointing anywhere useful yet. Before you can create alias records, you need a destination. A working S3 website gives you something real to point your DNS at.

In this step, you will create an S3 bucket configured for static website hosting. This gives you a working web endpoint that you will connect to your hosted zone in the next step.

In this step, get ready to:
  • Create an S3 bucket named to match your practice domain.
  • Enable static website hosting, upload an HTML page, and configure public access.
  • Test the S3 website endpoint in your browser.
Create an S3 bucket named after your practice domain

For Route 53 alias records to work with S3, your bucket name must be exactly the same as your domain name. This is a strict rule from AWS.

  • In the AWS Management Console, open the S3 console at https://console.aws.amazon.com/s3/.
  • Click Create bucket.
  • In the Bucket name field, enter your practice domain name exactly (e.g. nextwork-dns-lab.com).
  • For AWS Region, select the region closest to you (e.g. us-east-1).
  • Leave all other settings as defaults and click Create bucket.

Why must the bucket name match your domain?

When you connect Route 53 to an S3 website using an alias record, Route 53 checks that the bucket name matches the domain name exactly. If your domain is example.com, your bucket must also be named example.com. This is a common exam question.

You should see your new bucket appear in the S3 bucket list.

Enable static website hosting and upload your page

Your bucket exists, but it is just a storage container right now. You need to tell S3 to serve files from it as a website and upload some content to display.

  • Click your bucket name in the bucket list to open it.
  • Click the Properties tab.
  • Scroll down to Static website hosting and click Edit.
  • Select Enable under Static website hosting.
  • In the Index document field, enter index.html.
  • Click Save changes.

Note the Endpoint URL that appears under Static website hosting. You will use this to test your site shortly.

Now create and upload a simple HTML page.

  • On your computer, open a text editor and create a file named index.html with the following content:
<html><body><h1>Route 53 DNS Lab</h1><p>This page is served from S3.</p></body></html>
  • Save the file on your computer.
  • Back in the S3 console, click the Objects tab on your bucket.
  • Click Upload.
  • Click Add files and select your index.html file.
  • Click Upload to confirm.

You should see index.html listed in your bucket's Objects tab.

Configure public access so visitors can see your page

By default, S3 blocks all public access to your bucket. For a static website, you need to allow the public to read your files.

  • Click the Permissions tab on your bucket.
  • Under Block public access (bucket settings), click Edit.
  • Uncheck Block all public access.
  • Click Save changes.
  • A confirmation dialog will appear. Type confirm in the field and click Confirm.

Now add the bucket policy that grants public read access.

  • Still on the Permissions tab, scroll down to Bucket policy and click Edit.
  • Paste the following policy into the Bucket policy editor, replacing the bucket name with your actual bucket name:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::[[YOURDOMAIN=\"nextwork-dns-lab.com\"]]/*"
            ]
        }
    ]
}

What does this policy do?

This bucket policy says: let anyone on the internet (Principal: "*") read files (s3:GetObject) from your bucket. The /* at the end of the Resource line means all files in your bucket are included.

  • Click Save changes.

Seeing an error when saving the policy?

If you see an error about an invalid resource, the bucket name in the policy does not match your actual bucket name. Double-check that the Resource line reads arn:aws:s3:::yourbucketname/* with your exact bucket name. Also confirm you saved the Block Public Access changes.

Help me troubleshoot this bucket policy error.

Test the S3 website endpoint in your browser

Everything is configured. Confirm that the S3 website actually works on its own before connecting DNS.

  • Click the Properties tab on your bucket.
  • Scroll down to Static website hosting.
  • Click the Endpoint URL (it opens in a new tab).

Your HTML page loads in the browser, displaying a heading that says Route 53 DNS Lab. This confirms S3 is correctly serving your website.

Seeing 403 Forbidden or a blank page?

If you see 403 Forbidden, your bucket policy is not applied correctly. Go back to the Permissions tab, confirm Block Public Access is disabled, and verify the bucket policy is saved with the correct bucket name.

If you see 404 Not Found, confirm your uploaded file is named exactly index.html (case sensitive).

Help me fix my S3 website endpoint error.

Your S3 website is live. In the next step, you will connect your hosted zone to this website using a Route 53 alias record. This is where the difference between alias and CNAME becomes important.

Create an Alias Record at the Zone Apex

Your S3 bucket is live and serving your website through its endpoint URL. Now it's time to connect your hosted zone so DNS can resolve your practice domain to that S3 endpoint.

There's a catch. DNS rules say you cannot use a CNAME record at the very top level of your domain (like yourdomain.com with nothing in front of it). This top level is called the zone apex. Route 53 solves this problem with alias records. An alias record works like a shortcut to another address, but it gives back an IP address directly instead of pointing to another name.

In this step, get ready to:
  • Create an alias A record at the zone apex pointing to your S3 bucket.
  • Query your hosted zone's name server to confirm the alias resolves to an IP address.
  • Understand why alias is required at the zone apex and CNAME is forbidden.
Create an alias A record in your hosted zone

You can't use a CNAME record at the top level of your domain because DNS rules don't allow it. Route 53's alias record gets around this by giving visitors an IP address directly, while still pointing to your AWS resource behind the scenes.

  • Return to the Route 53 console in your browser.
  • In the navigation pane, click Hosted zones.
  • Click the name of your hosted zone.
  • Click Create record.

The record creation form appears. Configure each field as follows:

  • Leave the Record name field blank. This targets the zone apex (your bare domain).
  • For Record type, choose A – IPv4 address.
  • Toggle Alias to on.
  • Under Route traffic to, choose Alias to S3 website endpoint.
  • Choose the Region where you created your S3 bucket.
  • Select your bucket from the dropdown. It only appears if the bucket name matches your domain name exactly.
  • For Evaluate target health, choose No.
  • Click Create records.

Why A record type for an alias?

Route 53 needs you to pick A – IPv4 address as the record type when connecting to an S3 bucket. Behind the scenes, Route 53 looks up the IP address for your S3 website and gives that directly to visitors. To the outside world, it looks like a normal address record.

Alias lookups to AWS services like S3 are free. Regular CNAME lookups cost $0.40 per million. So alias records save you money too.

Don't see your bucket in the dropdown?

The bucket only appears if its name matches the record name exactly. Since you left the record name blank (zone apex), the bucket must be named identically to your hosted zone's domain. Double-check the bucket name in S3. Also confirm you selected the correct Region.

Help me troubleshoot why my S3 bucket doesn't appear in the Route 53 alias dropdown.

Confirm alias behavior with nslookup

Now you'll see the difference between alias and CNAME in action. When you look up a CNAME record, it gives you back another website name. When you look up an alias record, it gives you back an IP address directly, just like a regular A record.

Before you run the next command, predict what you expect to see. Will the response show a CNAME pointing to S3, or an IP address?

  • Query your domain against one of your hosted zone's name servers by running this command:
nslookup [[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

The response shows an A record with one or more IP addresses. There is no CNAME in the output. This proves that alias records give back IP addresses directly, even though they point to an AWS resource behind the scenes.

Why does this matter for the AWS exam?

The AWS exam often asks: your top-level domain needs to point to an AWS service like S3. What record type do you use? The trick answer is CNAME (which doesn't work at the top level). The correct answer is an alias A record.

You can't create a CNAME at the top level of your domain. Alias records don't have this restriction. They work anywhere, including the top level.

Seeing a different result?

If nslookup returns an error or no address, make sure you are using one of your four name servers as the last argument in the command. Without it, your query goes to public DNS which won't resolve an unregistered domain.

Help me understand my nslookup results for my Route 53 alias record.

Your hosted zone now connects your practice domain to your S3 website through an alias A record. Next up, you'll create more record types and see firsthand how CNAME behaves differently from alias.

Create Additional Record Types and Compare Alias vs CNAME

Your bare domain now points to your S3 website thanks to the alias A record from the previous step. The AWS exam often asks you to pick the right DNS record type for different situations.

In this step, you'll create CNAME, TXT, and MX records alongside another alias record. By comparing what each one gives back, you'll see exactly how they differ and why the exam tests this.

In this step, get ready to:
  • Create a CNAME record and an alias A record for subdomains to compare their behavior.
  • Add TXT and MX records for common email and domain verification scenarios.
  • Query each record type with nslookup to observe the DNS response differences.
Create a CNAME record and an alias A record for subdomains

Both CNAME and alias records can point a subdomain (like blog.yourdomain.com) to another address. The difference matters for the exam and for your AWS bill.

  • In the Route 53 console, navigate to Hosted zones and click on your hosted zone.
  • Click Create record.
  • In the Record name field, enter blog.
  • From the Record type dropdown, select CNAME.
  • In the Value field, enter your S3 website endpoint hostname from Step 2 (the URL shown under Properties > Static website hosting, without the http:// prefix).
  • Leave TTL at 300.
  • Click Create records.

Now create an alias A record for a second subdomain pointing to the same S3 bucket.

  • Click Create record again.
  • In the Record name field, enter site.
  • From the Record type dropdown, select A - IPv4 address.
  • Turn on the Alias toggle.
  • From the Route traffic to dropdown, choose Alias to S3 website endpoint.
  • Choose the Region where your S3 bucket lives.
  • Select your bucket from the list that appears.
  • Click Create records.

What is the cost difference between alias and CNAME?

Looking up alias records that point to AWS services like S3 is free. Looking up CNAME records costs $0.40 per million lookups. If a CNAME points to another record in your zone, you get charged twice because it takes two lookups.

On the exam, if both alias and CNAME would work for a subdomain pointing to an AWS service, alias is almost always the right answer because it's free and faster.

Now compare the DNS responses. Query the CNAME record against your name server by running:

  • Query the CNAME record by running:
nslookup -type=CNAME blog.[[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

You should see a line showing canonical name = followed by your S3 website address. This confirms the CNAME is working. Notice it gives back a name, not an IP address.

  • Now query the alias record by running:
nslookup site.[[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

You should see an IP address in the response. The alias gave back an address directly, not a website name. This is the key difference the exam tests.

Not seeing a canonical name or IP address?

Make sure you are including your name server as the last argument in each command. Without it, queries go to public DNS which won't resolve your practice domain. Also confirm you entered blog (not blog.yourdomain.tld) in the Record name field when creating the record.

Help me troubleshoot my CNAME or alias record not resolving.

Create TXT and MX records for email scenarios

TXT records store text information. They're often used to prove you own a domain or to set up email security. MX records tell email systems where to deliver mail for your domain. Both show up on the AWS exam.

  • In your hosted zone, click Create record.
  • Leave the Record name field empty (this creates a record at the zone apex).
  • From the Record type dropdown, select TXT.
  • In the Value field, enter "v=spf1 include:amazonses.com ~all" (include the double quotes).
  • Click Create records.

What is this TXT value?

This is an SPF record, which stands for Sender Policy Framework. It's like a permission slip that says Amazon SES is allowed to send emails for your domain. For the exam, remember that SPF information is always stored as a TXT record.

  • Click Create record again.
  • Leave the Record name field empty.
  • From the Record type dropdown, select MX.
  • In the Value field, enter 10 mail.nextwork-dns-lab.com (replace with your practice domain). The 10 is the priority number.
  • Click Create records.

What does the MX priority number mean?

The priority number decides which mail server gets tried first. Lower numbers go first. If you had two MX records with priorities 10 and 20, email goes to the server with 10 first. If that server is down, it tries the server with 20.

Compare DNS response behaviors across all record types

You've created four different record types. Time to see how each one responds at the DNS level.

  • Query the TXT record by running:
nslookup -type=TXT [[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

You should see your SPF string v=spf1 include:amazonses.com ~all in the response.

  • Query the MX record by running:
nslookup -type=MX [[YOURDOMAIN="nextwork-dns-lab.com"]] [[NAMESERVER="ns-XXXX.awsdns-XX.com"]]

You should see mail preference = 10 followed by your mail server hostname.

Quick reference: what each record type gives back

  • CNAME: gives back another website name. Your computer then has to do another lookup to get the actual IP address.
  • Alias (A): gives back an IP address directly. Looks like a normal record to the outside world. Free when pointing to AWS services.
  • TXT: gives back a text string. Used to prove domain ownership and set up email security.
  • MX: gives back a priority number and a mail server address. Lower number means higher priority.

The key difference:

A CNAME is visible in the response as a redirect to another name. The computer has to do a second lookup. An alias record is invisible as an alias. It just looks like a regular A record with an IP address.

This is why CNAME can't be used at the top level of your domain. DNS rules say a CNAME can't exist alongside other record types (like MX and NS), and those already live at the top level. Alias records don't have this problem because Route 53 handles them internally.

You now have hands-on experience with the most common DNS record types. You've seen that alias records give back IP addresses (they look like regular A records), while CNAMEs give back website names. This difference is the most frequently tested Route 53 topic on the AWS exam.

Secret mission

Add Weighted Routing to Distribute Traffic

Route 53 supports routing policies that go beyond simple one-to-one record mapping. Can you create a weighted routing policy that splits traffic between two S3 buckets and observe the load-balancing behavior from the terminal?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project has a small ongoing cost from the hosted zone ($0.50/month, free if deleted within 12 hours of creation).

Cost warning

Your public hosted zone charges $0.50 per month (free if deleted within 12 hours of creation). S3 storage for a single HTML file is negligible. If you complete cleanup within 12 hours, this project is effectively free.

Resources you used:

  • 1 public hosted zone ($0.50/month, free if deleted within 12 hours of creation).
  • S3 bucket named as your practice domain (negligible storage cost for a single HTML file).
  • S3 bucket named v2.yourdomain (Secret Mission only, negligible storage cost).

Keep everything running

No action needed. Choose this if you plan to continue experimenting with Route 53 routing policies or want to revisit your records later.

  • Ongoing cost is $0.50/month for the hosted zone plus negligible S3 storage charges.
  • Your S3 website endpoint remains accessible directly via its URL.

Pause - I'll come back to this later

DNS hosted zones are always active. There is no way to pause a hosted zone without deleting it. The only cost-reduction option is to delete the hosted zone and recreate it later.

  • Follow the Delete tab instructions for the hosted zone only. You can recreate it and your records later.
  • Keep your S3 buckets intact so you do not need to re-upload your website content.

Delete - I don't want to use this again

Remove all project resources. If you delete the hosted zone within 12 hours of creating it, you will not be charged.

Delete all DNS records and the hosted zone:

  • Open the Route 53 console at https://console.aws.amazon.com/route53/.
  • In the navigation pane, choose Hosted zones.
  • Click the name of your hosted zone to open it.
  • Select all records except the NS and SOA records.
  • Click Delete, then click Delete again to confirm.
  • Go back to the Hosted zones list page.
  • Select the row for your hosted zone.
  • Click Delete, type the confirmation key, and click Delete to confirm.

12-hour grace period

If you created the hosted zone less than 12 hours ago, you will not be charged for it.

Delete the S3 buckets:

  • Open the S3 console at https://console.aws.amazon.com/s3/.
  • Select the bucket named as your practice domain (e.g. nextwork-dns-lab.com).
  • Click Empty, type the confirmation text, and click Empty to confirm.
  • With the bucket still selected, click Delete, type the bucket name, and click Delete bucket.
  • Repeat for any additional S3 buckets you created (e.g. v2.nextwork-dns-lab.com from the Secret Mission).

Nice Work!

Nice Work!

You just created a Route 53 hosted zone, configured DNS records from scratch, and proved how alias and CNAME behave differently at the protocol level. You now own the single most tested Route 53 concept on the SAA-C03 exam.

Here's what you learned:

  • Created a public hosted zone in Route 53 and explored the NS and SOA records that form the foundation of DNS delegation.
  • Created an alias A record at the zone apex to route traffic to an S3 static website, understanding why CNAME is forbidden at the apex and alias is Route 53's solution.
  • Created CNAME, TXT, and MX records and used nslookup to observe how each record type responds differently at the DNS level.
  • Secret Mission: Configured weighted routing to distribute traffic across two S3 endpoints and observed the load-balancing behavior from the terminal.

Ready to quiz yourself?