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 > |
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
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.
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.
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.
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:
Again, if you need help, contact the registrar.
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.
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.
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.
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.
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.
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.
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.
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.