Skip to main content

Managing DNS Records with AWS Route 53

Hands-On Lab

 

Photo of Fernando Medina Corey

Fernando Medina Corey

Training Architect

Length

00:45:00

Difficulty

Intermediate

In this live AWS environment you will learn how to create and manage DNS records inside of Route 53. You'll start by creating a simple application. It will serve as a test website from two EC2 instances, and will route traffic using an Application Load Balancer ELB. After this, you will create two records inside a Route 53 hosted zone that will configure the DNS settings for a custom domain and point it to your application. Further, you'll look at how DNS works in this scenario (and in general) and how a command line utility like dig can get more information about a domain. These skills will allow you to associate many kinds of AWS web applications with recognizable web domains such as yourcoolsite.com. Here is a code snippet we'll need for this lab: #!/bin/bash yum update -y yum install -y httpd cp /usr/share/httpd/noindex/index.html /var/www/html/index.html service httpd start PLEASE ENSURE YOU USE THIS SNIPPET otherwise the ELB healthchecks will fail.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Managing DNS Records with AWS Route 53

Introduction

In this hands-on lab, we will learn how to create and manage DNS records inside of Route 53. We'll start by creating a simple application — which will serve as a test website — from two EC2 instances and route traffic using an Application Load Balancer. After this, we will create two records inside a Route 53 hosted zone that will configure the DNS settings for a custom domain and point it to your application.

We'll also look at how DNS works in this scenario (and in general) and how a command line utility like dig can get us more information about a domain. These skills will allow us to associate many kinds of AWS web applications with recognizable web domains such as yourcoolsite.com.

Creating EC2 Instances and an Application Load Balancer

If you haven't already done so, log in to the live environment as cloud_user with the password provided.

The first thing we're going to do is launch two instances.

Create the First EC2 Instance

In the AWS Management Console, navigate to EC2 via Services at the top. Click Launch Instance.

On the AMI page, select Amazon Linux AMI (not the Amazon Linux 2 AMI).

Next, select General purpose t2.micro from the list of instance types, and click Next: Configure Instance Details.

We'll leave Network as the default VPC. Under Subnet, select us-east-1e. For Auto-assign Public IP, select Enable. Before we move on, we need to write a user data script that will install and start a web server on the EC2 instances. To do this, go to the Advanced Details section at the bottom, and paste the following code snippet into the User data box:

#!/bin/bash
yum update -y
yum install -y httpd
cp /usr/share/httpd/noindex/index.html /var/www/html/index.html
service httpd start

Click Next: Add Storage.

We can leave the default settings here — the Size (GiB) should be 8GB and the Volume Type should be General Purpose SSD (gp2). Click Next: Add Tags.

Leave all the tag settings on this page (there shouldn't be any tags set), and click Next: Configure Security Group.

On the Configure Security Group page, we can leave the default Create a new security group setting under Assign a security group. Under Security group name, type "SG". Click Add Rule below, and then click the dropdown and select HTTP. We can leave the default settings that autopopulate for Protocol (TCP), Port Range (80), and Source (0.0.0.0/0, ::/0). Click Review and Launch.

We're going to get a warning at the top that our security group is wide open to the entire internet, but that's fine for this lab environment. In a real-world setting, we'd want to tighten it up.

Everything else should look good, so click Launch.

The final step is to create a key pair so we can use SSH to log in to the instance using a key pair. In the Select an existing key pair or create a new key pair pop-up, click the default Choose an existing key pair to open the dropdown, and select Create a new key pair. In Key pair name, enter "R53KP" and click Download Key Pair. Click Launch Instances.

On the Launch Status page, click View Instances.

Here, we'll see the status is pending. It may take a few minutes before it changes to running. While we're waiting, let's make our second instance.

Create the Second EC2 Instance

Navigate back to EC2 via Services at the top, and click Launch Instance.

On the AMI page, select the same Amazon Linux AMI again.

Next, select General purpose t2.micro, and click Next: Configure Instance Details.

We'll leave Network as the default VPC again. But this time, for Subnet, select us-east-1d. For Auto-assign Public IP, select Enable. Go to the Advanced Details section, and paste the following code snippet into the User data box:

#!/bin/bash
yum update -y
yum install -y httpd
cp /usr/share/httpd/noindex/index.html /var/www/html/index.html
service httpd start

Click Next: Add Storage.

We can leave the default settings again, so just click Next: Add Tags.

Leave all the tag settings on this page, and click Next: Configure Security Group.

This time, on the Configure Security Group page, we want to Select an existing security group under Assign a security group, and then check the box next to our SG security group we created a few minutes ago. Click Review and Launch.

Everything should be fine, so click Launch.

In the Select an existing key pair or create a new key pair pop-up, leave the default Choose an existing key pair, which should already have our R53KP set. Check the box to acknowledge we have access to the selected private key file, and click Launch Instances.

On the Launch Status page, click View Instances.

On the instances page, by now our first instance should have a status of running, and the one we just created is most likely pending.

In the IPv4 Public IP column, copy the IP address listed for the instance that's running. Paste it into a new browser tab, which should bring up an Amazon Linux AMI Test Page.

Create the Application Load Balancer

Back in the EC2 console, click Load Balancers in the sidebar (under LOAD BALANCING). Click Create Load Balancer.

Elastic load balancing supports three types of load balancers: Application Load Balancers, Network Load Balancers, and Classic Load Balancers (which are slowly being phased out).

For this lab, we need an Application Load Balancer, so in the Application Load Balancer section, click Create.

In the Basic Configuration section, give it a Name of "ELB" (for "Elastic Load Balancer"), make sure Scheme is set to internet-facing, and set IP address type to ipv4. Leave the defaults in the Listeners section. For Availability Zones, check both us-east-1d and us-east-1e. Click Next: Configure Security Settings.

We aren't using HTTPS, so we don't have to do anything on the security settings page. Click Next: Configure Security Groups.

For Assign a security group, select Create a new security group. For Security group name, enter "ELBSG", and leave the defaults in the table below. Click Next: Configure Routing.

In the Target group section, select New target group. Give it a Name of "ELBTG", and leave the default settings for Target type (Instance), Protocol (HTTP), and Port (80). Leave the Health checks settings as they are. In the Advanced health checks settings section, leave everything as it is, but change the value for Healthy threshold to 2 (instead of the default 5). This will speed things up when we're running health checks for our Application Load Balancer. Click Next: Register Targets.

In the Instances section, check the box next to both of our EC2 instances. Then, click Add to registered above the instances table, which will move our EC2 instances to the Registered targets section above. Make sure they show up there before clicking Next: Review.

Everything should be good on the Review page, so click Create. Then click Close.

On the load balancer screen, under Description at the bottom, we should see a DNS name for our Application Load Balancer. Copy and paste it into a new browser tab, where we'll see we currently can't reach it. This is because our Application Load Balancer is still in the provisioning state.

In the meantime, head back to the EC2 console, and click Instances in the sidebar (under INSTANCES), and let's check that both of our instances are running. Copy the IP address of each instance, and paste them both into new browser tabs. Both should properly serve web traffic over port 80 in our browser, displaying the Amazon Linux AMI Test Page.

When our Application Load Balancer is finally finished provisioning, it should display a state of active. It might take a few minutes. If it doesn't show that state, refresh it to see if it just hasn't updated yet. Once it's active, go back to the browser tab with its DNS name, and refresh it to make sure it displays the same Amazon Linux AMI Test Page.

Now that this is all set up and properly configured, we're ready to use our Application Load Balancer and our instances' IP addresses for the next step.

Configuring Route 53 DNS Record Sets

We now want to set up the Route 53 DNS record sets to point to the Application Load Balancer whenever a user navigates to a custom domain name in their browser. Our Application Load Balancer currently has a not-so-pretty domain name, and we want to set up a custom domain name we can send users to so they can interact with our application. Now, let's see how we can do this with Route 53.

Back in the AWS console, navigate to Route 53 via Services (under Networking & Content Delivery).

A custom domain name has already been registered for you, so you don't need to worry about registering one here.

When we're working with Route 53, the first thing we need to deal with is hosted zones. Click Hosted zones, where we'll see a domain name listed — it should be something along the lines of cmcloudlab990.info. Click the domain name, and let's take a look.

We'll see we have two record sets: one with a Type of NS (which stands for "name server") and one with a Type of SOA (which stands for "start of authority"). These are the only ones we need — if you see more than two, like NA, you can delete them. We just need NS and SOA.

Copy the domain name of the NS type, and paste it into a new browser tab. We should see it can't currently be reached. So if a user were to try and access this URL, it wouldn't be found. We need to configure it so that when someone navigates to this domain name in a browser, the user is redirected to the Application Load Balancer's IP address or the IP addresses of the EC2 instances that are serving our application.

Here's a quick sidetrack to talk about how that works.

What Happens When We Access a Custom Domain Name

When we paste this custom domain name into the browser, our browser is going to check to see if it has the IP address cached in the browser or if it's cached at the operating system level. In this case, it doesn't, so it will go over to the ISP we're using and check if the ISP's DNS resolver has information about where to go for the domain name. The ISP's DNS resolver will have a bunch of caching in place, so it will likely know both the location of the website and the locations of name servers, such as the .com top-level domain name server.

If we navigate to a certain domain name, but don't know where it is, we'll ask the ISP's DNS resolver. If it doesn't know, it will ask the root name server where to go. If it doesn't know, it will then move on to the .com name server, which is another server that has more information about the .com top-level domain. If that one doesn't know, it will move the process to the ISP's DNS resolver yet again. Once it has the name servers, it knows where to go to look for more information about the site, and the ISP's DNS resolver will ask Route 53 if it knows where to find the site. Route 53 is the service we're using to have the name servers in the background tell us where to find the website we want to find at the web address.

We're going to do a few things to make Route 53 always point to the correct IP address. Before we work on that part of the lab, let's dig a bit more into this process.

The Command Line Tool dig

We're going to do a little more research using the command line tool dig, which allows us to run the process we just discussed without the need for a web browser.

In a terminal, run:

dig www.linuxacademy.com

We'll see some information about some of the hops we're going through when we're looking for the particular place to find www.linuxacademy.com. Essentially, the question we asked dig was, where can we find www.linuxacademy.com? It's going to give us some answers, including the IP addresses that currently host the website. If we copy one of these IP addresses and paste it into a new browser tab, we'll land on www.linuxacademy.com — it will essentially redirect and show the domain name in the window.

It will also give us information about the name servers for the domain, as well as information about the particular name servers and other information for the IPv4 and IPv6 addresses. We're not going to get too deep into this, but it's good to know we can use this.

If we wanted more detailed information, we could enter:

dig www.linuxacademy.com +trace

This would essentially go through all the hops, so we'll see all the root servers, top-level domain servers, and name servers, which finally say where we can find the IP addresses for the domain name we're looking for.

Let's continue with the lab and head back to Route 53 in the AWS console.

Create the Record Sets

What do we need to do to make this process happen for our own custom domain name in Route 53?

We need to add a few records to the record sets for this domain. The records will tell Route 53 where to look for the physical machine that's hosting our service to send traffic to that machine.

Click Create Record Set. For Type, set it to A – IPv4 address.

We could use an alias, or we could choose not to use an alias. Aliases allow us to point to particular things, like Application Load Balancers or Classic Load Balancers as well as S3 static websites. The reason we have these inside AWS is because the actual IP address for these different services may change. Behind the scenes, AWS has a bunch of different web servers that, on any given day, might be hosting this different information. These servers may be switching IP addresses around. So if we choose a target alias for the Application Load Balancer, whenever the record set is asked for the record for this particular non-www domain, it's going to check the actual domain that's currently set up for this Application Load Balancer and then check the IP address currently set up for the domain. It will then route us there instead of a static IP address.

Set Alias to Yes. For the Alias Target, set it to the ELB listed under ELB Application load balancers. Click Create. We should now see a new record set listed with a Type of A.

Click Create Record Set again. This time, type "www" in the Name box. Leave Type set to A – IPv4 address. Then, set Alias to Yes, and select the ELB again for Alias Target. Click Create. Now, we should have two A records, one for each version of our domain (both the non-www and the www).

Now, go back to the browser tab with our domain and try refreshing it again. It should still prevent us from going to the domain because the information in our record sets has to get sent out to the name servers, so it needs a little while to propagate. Wait a few minutes and then refresh.

>Note: They could take up to 15 minutes to finally show up, so don't panic if they take longer than you expect. The www and non-www versions might even take different amounts of time to properly load when you try to access the URLs. You could even use dig to check the records and see if they are in yet.

Once some time has passed, refresh it again, and we should finally be able to navigate to the Amazon Linux AMI Test Page from our custom domain.

Conclusion

Congratulations on completing this lab! We've now successfully used Route 53 to create DNS record sets that point to an Application Load Balancer, which is then routing traffic between multiple EC2 instances. This allows us to have a custom domain name and a highly available, scalable load balancer application.