This is part four in our series on how to deploy an app to AWS with the least effort.
The series covers:
- Getting started
- Preventive measures
- App security
- Route 53 and DNS explained (this post)
- App automation and optimization
Today, we're going to focus on DNS (domain name system), specifically the AWS DNS service Route 53.
As you're deploying your web app, you will inevitably use DNS. If you’re deploying on AWS, then you should be using Route 53 for a couple of reasons: it uses IAM for authentication; it tightly integrates with EC2, S3, CloudFront, and more; and it has smart mechanisms for global failover and health checks. Even if you don’t use all of those features now, it’s so simple to switch and cheap to run that you should do it anyway.
Since you’ll certainly use Route 53 and you want to get your app running as quickly as possible, I’ll cover exactly what you need to know about DNS, Route 53 specifics, DNS record types, and how to work with other AWS services.
| Got any plans for monitoring your soon-to-be-deployed app? Blue Matador is the fastest, easiest way to monitor AWS. Learn more > |
DNS explained
As we wrote above, DNS stands for "domain name system." Here are the basics about how it works: All computer networks use IP addresses (numbers) as unique locators. DNS is the system that converts domain names and subdomains into those IP addresses. DNS is usually available on port 53 over TCP and UDP but runs as a normal process on a normal server.
Because anyone can host and spoof DNS by listening on port 53, it’s critically important to designate an authoritative source. When you register a domain name, like bluematador.com, the registrar (like GoDaddy or Route 53) becomes the authoritative source for DNS queries.
Every DNS record has a name, a type, a value, and a TTL, which is basically a time requirement for caching. You can use utilities like dig to query for DNS records. As an example, the entry app.bluematador.com returns multiple A type records to specify the IP addresses where the app can be reached:
$ dig +noall +answer app.bluematador.com
app.bluematador.com. 59 IN A 52.204.155.101
app.bluematador.com. 59 IN A 3.219.17.34
app.bluematador.com. 59 IN A 100.26.62.211
Route 53 is simply Amazon’s implementation of DNS, including configuration and integration with other AWS 
services. Just like every other DNS provider, AWS Route 53 allows you to manage domain names, subdomains, and other types of records. You can manage Route 53 in the AWS console, through API calls, and through the aws-cli command-line utility.
How to make Route 53 authoritative
A DNS provider needs to be authoritative. If Route 53 is not authoritative, then your changes will not be reflected on the public internet.
There are only three ways to make your Route 53 domains authoritative. From easiest to hardest, you could buy your domain through Route 53, transfer the domain to Route 53, or update the NS records in your existing registrar.
How to buy your domain through Route 53
If you haven’t already bought your domain, then just buy it straight from Route 53. It’s straightforward to search for domains and purchase them. (I’m unfamiliar with their ability to negotiate and broker deals for already-owned domains. If that’s your goal, you’ll have to do separate research.)
In fact, the process is so easy, it doesn’t even deserve screenshots. Go to the domain registration page, pick your domain, and buy it. It will automatically get set up in Route 53 in the following 24 hours, where it will be authoritative and ready for action.
How to transfer your domain to Route 53’s registrar
Transferring your domain to Route 53 is like transferring a phone number to a new carrier. Both carriers need to be involved, and there will be verification steps to make sure the domain isn’t being stolen.
Amazon has a wizard for requesting a domain transfer. To initiate a transfer, go to the Registered Domains tab on Route 53 and click “Transfer Domain.”
The wizard will check for things like transfer locks, which can be adjusted in your current registrar.
Make sure you copy all your DNS records over to the new hosted zone as soon as you can. If you don’t, you’ll have some downtime.
How to update the NS records in your existing registrar
Skip this section if you can do either of the previous two - they’re MUCH better!
Because of the sheer number of registrars out there, it's not possible to give instructions that match your exact situation, but I'll explain what’s going on and the general process you should take to switch the NS records to make Route 53 authoritative.
All registrars have their own DNS system where you can update the records. There’s a record, called an NS record, that specifies where DNS queries should be directed. By default, it’s always the registrar you got the domain name from. Changing the NS record changes where DNS queries will go. It does not change the authority of your registrar. To do that (not necessary), you’ll need to transfer the domain altogether.
Changing the NS records will require a couple steps:
- Create a new Hosted Zone in Amazon Route 53.
- A DNS hosted zone is a domain name. Go to the Route 53 console, select “Hosted Zones” and click “Create Hosted Zone.” Enter your domain name and click “Create.” The zone shouldn’t work yet (it’s not authoritative), but it will exist.
- Duplicate the DNS in your registrar to Route 53.
- If you have any A, AAAA, CNAME, MX, or other records in your registrar’s DNS, duplicate them to Route 53 now. Do not duplicate NS or SOA records. The duplication makes sure you don’t lose service after the next step.
- Change the NS records.
- Look in the new Route 53 hosted zone. There will be an NS record with 4 values that look something like “ns-1577.awsdns-05.co.uk.” Replace all NS records your registrar has with all 4 values from Route 53. If you’re not sure how, ask your registrar for support.
- Wait for about 24 hours.
- NS records take a while to take effect. Refreshing does not help. Just come back in a day.
- Verify that it’s working.
- Without losing service, the easiest way to check if it’s working is to create a new record in Route 53, and then use dig or an online DNS query utility to see if the record resolves. It may take a few minutes to an hour for your Route53 changes to propagate, so be patient. If it’s been over an hour, try creating another record (I’ll talk about negative TTLs below).
- Delete all old records in the registrar.
- At this point, you can delete all the records in your registrar, except for NS or SOA records. You don’t need to delete them, but they’re both worthless and misleading because anybody looking at the list would think changing them would work.
Again, if you need help, contact the registrar.
Hosted zones and DNS records
Okay, the hard part is over. You’ve got a hosted zone in Route 53, and now you’re wondering how to use it. As I said before, every DNS record has 4 parts: the name (app.bluematador.com), the type (A), the value (3.219.17.34), and the TTL in seconds (59).
Let’s go over the different DNS record types.
|
There are more DNS record types than this, but those are the ones you'll primarily use in deploying your application.
As for the name of records, it will always be a subdomain, like “dev.bluematador.com” or “www.bluematador.com.” Every subdomain can point at a single application, and there is no cost to the number of subdomains hosted.
The DNS record value will come from whatever service you’re integrating. I’ll go over that next.
Finally, the TTL will seem arbitrary. In large part, it is, except that low values are required by AWS to allow changing infrastructure. The default value is 300s (5 minutes), but the recommended value when working with ELBs, S3, and most other services is 60s (1 minute). I recommend using 1 minute in all A, AAAA, and CNAME records.
Route 53 alias records
There is one feature of Route 53 that requires special callout and attention—alias records. These don’t exist in most DNS systems, and certainly aren’t part of the DNS standard. Alias records are Amazon’s way of addressing some shortcomings of the DNS specification.
DNS doesn’t allow CNAMEs to be used in the apex record. So, if you’re trying to make a CNAME from “bluematador.com” (the apex—meaning “no subdomain”) to “www.bluematador.com,” then you can’t do it—unless you use an alias record.
An alias record is exactly what it sounds like. It’s a symlink, which is a self-resolving record that doesn’t take an extra hop by the client to resolve.
You will be using alias records for static website hosting in S3, CloudFront distributions, ELBs, and apex domains.
How to use Amazon Route 53
The nice thing about Route 53 is that it’s so simple if you use just its core feature set—DNS records for hosted zones. Integrating it with other services is straightforward and fast to do.
Let me give you some examples. In all of these examples, there are different ways you could accomplish the same thing. For example, instead of creating a CNAME record to an EC2 instance’s public hostname, you could create an A record to its public IP address. I will be giving the best practices for each individual example.
- For an EC2 instance, use an A record with the instance’s public IP address as the value. The TTL should be 60 seconds. If you’re using an elastic IP address (you probably should), then the TTL can be 3600 seconds (an hour).
- For an S3 bucket, use a CNAME record to “<bucketname>.s3.<region>.amazonaws.com.”. The TTL may be 3600 seconds. Your bucket name must match exactly the name of the subdomain—if your bucket name is something like “mybucket,” then it won’t work. For a subdomain of “cdn.bluematador.com”, your bucket name must be “cdn.bluematador.com,” and your CNAME would be “cdn.bluematador.com.s3.us-east-1.amazonaws.com.” Keep in mind that SSL will not work on that URL (the certificate won’t match the URL). To get SSL with your subdomain on S3, you’ll have to use CloudFront in front of S3.
- For an S3 bucket with website hosting, use an A record with alias to the bucket. Using an alias record will provide a drop-down option in Route 53. If it doesn’t appear, refresh your page. The name of the bucket must be identical to the subdomain you’re using, same as the S3 bucket in the paragraph above. Alias entries don’t need a TTL.
- For an ELB, ALB, CLB, or NLB, use an A record with an alias to the ELB. Again, an alias won’t require a TTL and will provide a dropdown option for the ELB’s alias target.
- For a CloudFront distribution, use an A record with alias to the distribution.
- For an API gateway, use an A record with alias to the gateway.
Route 53 can be used for many more services than those listed above, just keep in mind that many times AWS will use the hostname as an identifier, and using a CNAME doesn’t transmit the underlying hostname. That’s why S3 doesn’t work without a matching bucket name.
Other Route 53 features
You probably won’t use these now, but I want to bring it up so you can be aware of it and use it later.
Other DNS record types
- MX stands for “Mail eXchange” and is used to identify an email server. Your email provider will have documentation around how to set these up.
- TXT is plain text, and is only really good for validating domain ownership with tools like Google Analytics or email validation.
- SPF stands for “Sender Policy Framework” and can help increase your email deliverability. I won’t go into this here, but since you’re making a web app, you should know what this is.
- SOA stands for “Start of Authority” and looks cryptic. You’ll have to look up the exact syntax of this value, but it’s helpful to reduce negative TTLs—the time you spend waiting for a new record to appear on the public internet. The default is usually a day, meaning that if you query “abc.bluematador.com” and then add it to Route 53, it will take a day to show up. If you reduce the negative TTL in the SOA record, you can reduce that time spent waiting.
Private hosted zones
Remember how anyone can create and host DNS by listening on port 53? You can use that to your advantage by using Route 53 internal zones in VPC. If you want an IP address for an internal database server, but don’t want that IP available to the public, use an internal zone, and associate it with your VPC.
DNS health checks
You can (and should) also use Route 53 to manage traffic between the same application hosted in different regions. You can route traffic by latency, shortest path, or health. This is all set up in Route 53.
Conclusion
As you're launching your app, you should make sure you have a basic understanding of DNS. Using AWS Route 53 is the best way to manage your domains if you're launching to AWS. Hopefully this primer has gotten you everything you need to make your Route 53 domains authoritative and successfully use Route 53 with other AWS services.
