I love bus rides. They give me great satisfaction and enable some peace within me.
Once, we wanted to redirect the user to our web app, and my colleague said we should use Route 53. After looking it up on the map, I went to the AWS documentation to learn about Route 53; its different from bus routes, but similar 🙃
Unless you start a new project, working with DNS doesn't happen very frequently. So I'll use this post as an opportunity to refresh my knowledge in this area and share the learnings, providing a high level guide into DNS and Route 53.
Disclaimer: There might be some cost associated with the resources you provision according to this post.
Introduction
Route 53 connects internet traffic to appropriate servers hosting the requested web application. It offers domain registration, routing and health-checking services.
We will start with a detailed explanation about "Domains" and their management then progress through the post to register a new website in AWS Route 53.
What is a DNS
As Route 53 offers a scalable DNS, we will explain it first. DNS or Domain Name System is a service that helps discover systems/applications on the internet and in private networks. Every day when you open your browser and access a website, some assets (or files) get downloaded to your browser, and through some magic involving HTML, CSS and JS, the website renders in a pleasant and friendly manner. These files are your web app content and need to be downloaded from a server on the internet. Your browser needs to figure out which server is that.
Each server on the internet has an IP address (similar to your home address but virtual). Assume we've requested www.amazon.com in the browser; our browser needs to figure out the IP address associated with that URL. The Domain Name System helps the browser figure out that address, which gets queried for content. This process happens in the background and is invisible to the user.
How does it work?
DNS is a vast distributed hierarchical database with lists of records mapping each domain name (e.g. amazon.com) to its corresponding IP address (e.g. 104.71.134.207). These mappings exist in a text file called zone file, which describes a DNS zone. A DNS zone is a managed area of the DNS that contains multiple subdomains.
How would we know the location of the zone file so that we query it for the domain name and its associated IP?
The zone file is hosted on a DNS Server called Name Server (NS). One of the features provided by DNS is a DNS resolver, a tool that sends and receives queries to and from NS servers on behalf of the client. The DNS resolver could be located on your machine (e.g. Laptop, PC, Phone) or running on a server that belongs to your internet provider.
How to reach these Name Servers?
That's a long section, so bear with me.
The domain name entered in the browser is read from right to left. This domain has a hidden . at the end, which gets added by the browser on our behalf (Try typing www.amazon.com. instead of www.amazon.com -> it will resolve into the same website). That . at the end is the root that gets read first by your computer.
DNS has a starting point, and that's the DNS root. The root zone is similar to any other zones of the DNS database, another managed area; it is at the top of the DNS hierarchy. There are 13 DNS root servers operated by 12 organisations (they manage the servers, not the database). The root servers host the root zone, managed by IANA.
The OS providers store on your machine a file called root hints file that has the list of the root servers (the hints file exists on the DNS resolver server as well, which could be hosted by your internet provider). In your terminal, type dig . ns to get the list of root servers:
; <<>> DiG 9.10.6 <<>> . ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 516045 IN NS a.root-servers.net.
. 516045 IN NS b.root-servers.net.
. 516045 IN NS c.root-servers.net.
. 516045 IN NS d.root-servers.net.
. 516045 IN NS e.root-servers.net.
. 516045 IN NS f.root-servers.net.
. 516045 IN NS g.root-servers.net.
. 516045 IN NS h.root-servers.net.
. 516045 IN NS i.root-servers.net.
. 516045 IN NS j.root-servers.net.
. 516045 IN NS k.root-servers.net.
. 516045 IN NS l.root-servers.net.
. 516045 IN NS m.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 516045 IN A 198.41.0.4
a.root-servers.net. 516045 IN AAAA 2001:503:ba3e::2:30
b.root-servers.net. 516045 IN A 199.9.14.201
b.root-servers.net. 516045 IN AAAA 2001:500:200::b
c.root-servers.net. 516045 IN A 192.33.4.12
c.root-servers.net. 516045 IN AAAA 2001:500:2::c
d.root-servers.net. 516045 IN A 199.7.91.13
d.root-servers.net. 516045 IN AAAA 2001:500:2d::d
e.root-servers.net. 516045 IN A 192.203.230.10
e.root-servers.net. 516045 IN AAAA 2001:500:a8::e
f.root-servers.net. 516045 IN A 192.5.5.241
f.root-servers.net. 516045 IN AAAA 2001:500:2f::f
g.root-servers.net. 516045 IN A 192.112.36.4
g.root-servers.net. 516045 IN AAAA 2001:500:12::d0d
h.root-servers.net. 516045 IN A 198.97.190.53
h.root-servers.net. 516045 IN AAAA 2001:500:1::53
i.root-servers.net. 516045 IN A 192.36.148.17
i.root-servers.net. 516045 IN AAAA 2001:7fe::53
j.root-servers.net. 516045 IN A 192.58.128.30
j.root-servers.net. 516045 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 516045 IN A 193.0.14.129
k.root-servers.net. 516045 IN AAAA 2001:7fd::1
l.root-servers.net. 516045 IN A 199.7.83.42
l.root-servers.net. 516045 IN AAAA 2001:500:9f::42
m.root-servers.net. 516045 IN A 202.12.27.33
m.root-servers.net. 516045 IN AAAA 2001:dc3::35
;; Query time: 11 msec
The DNS resolver uses the "root hints file" to query the root zone on the DNS servers. The DNS uses a delegation system to serve the IP back to the browser. That's how the resolver figures out the Name servers address containing the zone file pointing to the address of our web app location.
- First, the DNS root zone receives the request for the domain entered in the browser (e.g. www.amazon.com) through the DNS resolver
- The root zone has records for top-level domains (.com, .co, .org, .nz). So it responds to the resolver saying that it doesn't know the IP address of the full domain requested, but knows the name servers that host the zone files for the
.comdomains, and returns it to the resolver - At this point, the DNS resolver sends the request to the
.comname servers, hosting the .com zone - The
.comzone doesn't find the full www.amazon.com domain on its zone files, but finds records foramazon.com, which gets returned to the resolver - The DNS resolver sends the request to the servers hosting the zone file for the amazon.com zone. The records of the amazon.com zone would have a DNS record that maps
wwwto the appropriate IP address, which the browser needs. This IP address gets communicated back to the DNS resolver and the browser.
The flow looks as follows:
Would this happen every time we request a website?
As you might have noticed, that's a long round trip from when the browser requests a domain name until they get its IP address. The DNS resolver relies on a TTL (Time To Live) property returned along with the IP address from the name servers to make the process faster. When another client queries that exact domain name within that TTL, the resolver serves a cached version of the content initially returned. The response from the cache is called a Non-authoritative answer, while the original one returned from the name servers is an authoritative (trusted) answer.
Route 53
Amazon Route 53 is a Global scalable, performant and reliable service that provides domain registration, routing and health checks. It is a scalable, performant and reliable service.
Domain Registration
The first service offered by Route 53 is domain registration, giving a name to your website (e.g. www.amazon.com). Below is a summary of the process:
- In AWS Console, navigate to Route 53, and select Registered Domains
- Search if the name you want is available, then register it giving the contact details requests
The following actions happen when registering a domain:
- A hosted zone gets created specifying the servers to which the routing should happen when your domain is requested; that's the zone file explained previously, which contains the mapping between the domain name and the IP address of your web app
- That hosted zone gets associated with four name servers. When the user enters your website name in the browser, these name servers would look in the hosted zone (zone file) for the name of your website, gets the associated IP and returns it to the DNS resolver
- Route 53 adds the name server records to the top-level domain registry (.com in case of amazon.com) so that they are identified when the domain is requested
Route traffic to your Web App
Now that we registered the domain, we'd want to link it to the web app so that users can access our content. We create records in our hosted zone to route traffic to our web app (or other resources). Below is a summary of the most used record types:
- Nameserver (NS) -> tells the internet where to find out the domain's IP address. If you have a look at the "Hosted Zones" in the AWS console, you'll notice that a record has been already created pointing out to the four name servers earlier mentioned
- A and AAAA records -> Map hostnames to IP addresses (The A record maps to the IPv4 address, and the AAA record maps to the IPv6 address)
- CNAME Records (Canonical names) - These are aliases to other domains. On the opposite of an A/AAAA record, it points to a domain rather than an IP address. Usually, it is used for subdomains (e.g. blog.example.com). So instead of having an A/AAAA record for every subdomain to point to the same IP address, we create a CNAME record from the subdomain to the domain. This way, when the subdomain is requested, it triggers another DNS lookup to the domain returning the IP address via the A record. that is useful if we decide to change the IP address - we change it in a single place on the A/AAAA record. The CNAME records stay the same.
To put this into practice, let's create a website and host it on S3. You can follow the steps here: https://docs.aws.amazon.com/AmazonS3/latest/userguide/EnableWebsiteHosting.html, or use the following blog post automating the process with AWS CDK: https://medium.com/swlh/host-a-static-website-on-s3-using-aws-cdk-b9151213aad4. Note that for this to work, the name of the bucket in S3 should be exactly your domain name (e.g. example.com or www.example.com)
We want to serve the content added to the S3 bucket when our registered domain is requested. Below are the steps to add the records for your domain:
- In AWS console, navigate to Route 53, and select your hosted zone
- Click "Create Record", then click "Switch to wizard" on the next screen
- Select "Simple routing", and click "Next"
- Click "Define simple record"
- In the "Record name" field, keep the default, which is the name of your hosted zone and domain
- In the "Record type" field, keep the default, which is A record
- In the "Value/Route traffic to" field, select Alias to S3 website endpoint, a region and your S3 bucket endpoint (you can get the endpoint by going to your S3 bucket --> Properties --> Static website hosting at the bottom of the page) - for the endpoint enter this piece of the endpoint copied from S3: s3-website-.amazonaws.com
- Choose No for Evaluate target health
Once Done, open your website in the browser - it should take about 60 seconds to show correctly.
I hope this was useful. Please let me know your thoughts
Latest comments (0)