AWS Route53 – Creating and Using a Hosted Zone

AWS Cloud

AWS Route53 provides DNS Resolution (and DNS Registrar) services. You can use Route53 to register a domain, host the zone file and provide DNS resolution, alternatively, you can have the domain registered elsewhere, but then use Route53 to host the zone file and provide DNS resolution. There are some different options here, Route53 ties nicely into the AWS ecosystem, which means that there’s lots of options to automate DNS record use with the AWS services, which are not necessarily impossible with other DNS hosting providers, but will require additional coding and automation.

Example: We have the domain, which has been registered by the registrar Namesco, currently Namesco provide DNS Name Servers and host the Zone File. We’re going to setup an AWS Route53 hosted zone, copy the DNS records to it, then swap over to use AWS’s DNS Name Servers to host the domain; from there we can then do some testing!

A Hosted Zone can be created as Public Hosted or Private Hosted, this determines how you can use the hosted zone. If it is Public Hosted it may be used by Internet clients to resolve the DNS records, if it is Private Hosted, it may be used by services/instances within VPC(s) to resolve DNS names to IP addresses. Note that you cannot (currently) swap a Public Hosted Zone to Private or vice versa, if you need to do this it requires you to recreate from scratch.

DNS is not instant, if you have made a change, but its not being reflected, it can take time for propagation, also numerous levels of caching can be present, so you may need to wait, or clear your local DNS cache.

Step 1 – Create Hosted Zone

Firstly you need to create a “Hosted Zone”, this can be automated with Cloudformation or Terraform if you require.

Enter the details and click “Create Hosted Zone”.

Step 2 – Populate DNS Zone File with Records

Next we want to copy the existing DNS records from the current provider, in your case if you are setting up a new DNS zone you won’t necessarily need to do this, bear in mind things like the SOA record have been added for you automatically, so you probably don’t need to adjust these.

Click on the Hosted Zone Name to open it.

Create the relevant DNS records as you require, for example the below. Don’t worry about the Name Servers at the top (under Hosted Zone Details), we’ll come onto that in the next step.

As you can see I’ve added some DNS records, copied from the Nameco DNS control panel, in this example.

So we now have a Hosted Zone with a load of records on it, but clients on the Internet cannot yet reach this Hosted Zone to resolve addresses, because currently the domain is set to use Nameco’s DNS Name Servers, not AWS’s, we’ll change that in the next step; however let’s try something first.

Firstly, we’ll look at one of the DNS Name Server name’s and resolve it to its IP address, so let’s try: which has the IP address:

Now we’ll query that DNS Name Servers directly, so let’s try resolving to see what happens.

ubuntu@development4:~$ dig @
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64149
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available
; EDNS: version: 0, flags:; udp: 4096
;         IN      A
;; ANSWER SECTION:  3600    IN      CNAME
;; AUTHORITY SECTION:      172800  IN      NS      172800  IN      NS      172800  IN      NS      172800  IN      NS
;; Query time: 7 msec
;; WHEN: Sat May 25 15:21:12 BST 2024
;; MSG SIZE  rcvd: 210

Great, as you can see AWS is now able to resolve DNS records as expected, so we’re ready to repoint the Domain to use AWS’s Name Servers.

Step 3 – Repoint Domain to Use AWS Name Servers

Depending on your original DNS Registrar and who your current DNS Name Servers are held by, these steps may differ, but essentially all you need to do is set on your existing DNS Registrar’s control panel that the DNS Name Servers should now be what have been setup for your domain, in our example these are as follows:

Don’t worry if your current DNS Registrar only allows you to have two, or three DNS Name Server records, as long as you have more than one, you’ll have a resilient name resolution as provided by Route53.

The change to the DNS Name Servers can take a number of hours to propagate, i.e. for existing cached records to time out and for DNS resolvers to learn that the domain now uses AWS’s Name Server records.

Step 4 – Testing

Once the DNS Name Servers are referring to the AWS Name Servers, then we can perform a test, let’s try the DIG command again, but this time we don’t specify the DNS Server specifically, we want the DNS resolution to go to the root to start the resolution.

ubuntu@development4:~$ dig
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35392
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 65494
;         IN      A
;; ANSWER SECTION:  3600    IN      CNAME       21600   IN      A       21600   IN      A       21600   IN      A
;; Query time: 31 msec
;; WHEN: Sat May 25 15:28:11 BST 2024
;; MSG SIZE  rcvd: 123

Lovely, just what we want to see.

To check, if your old DNS Registrar allows it, you can make changes to the DNS Zone File there (in this case Nameco), you’ll notice that even after a number of days, DNS lookups you perform won’t reflect the changes, because although there may be a Zone File for the domain hosted there, nothing is set to point DNS requests from clients to it anymore!

The Route53 Hosted Zone is now ready for use.

DNS Record Types

The DNS record types that AWS Route53 uses are the same as any other DNS server, but there is an AWS specific record worth mentioning and that is the “Alias”.

Alias – The “Alias” record can be considered to be much like a CNAME record, i.e. a shortcut or pointer. AWS provide a great comparison in the article Choosing between alias and non-alias records but to pull out the probably most important one is how “Apex” or “Root” record is used in a domain. Let’s take the example, now we might have a website running for the domain which is being hosted using AWS Cloudfront. AWS Cloudfront provides a CNAME for your particular distribution (of your website), and so you can point say your record as a CNAME to the AWS Cloudfront endpoint CNAME, e.g. Now that’s fine for a DNS record like, but not everyone wants to type in the “www” part, so we want to have the “Apex” or “Root” record to use an Alias to point at the AWS Cloudfront distribution, because we can’t just put a CNAME in for the “Apex”/”Root” domain record. If we didn’t have an Alias available, we’d have to use an IP address in the “Apex”/”Root” record and that risks outages, because the IP addresses use by the AWS Cloudfront change on a regular basis.

(question) If when using an AWS Cloudfront Distribution with an Alias, you may not see it as a target, ensure the following is the case:

  • Only A records and AAAA are supported. Not CNAME records.
  • The Route53 “Alias Target” box matches against CloudFront distributions’ “Alternate Domain Names” field. If you’re creating a new record set for, you should have already set the alternate domain name for one of your distributions to
  • The Route53 Management Console can be slow, and it might not find your distribution right away — wait until the distribution status is Deployed.

Leave a Reply

Your email address will not be published. Required fields are marked *