Introduction to Route 53
Introduction to Route 53
Join the DZone community and get the full member experience.Join For Free
Route 53 is the scalable DNS service from AWS. It’s fairly simple and straightforward, and Amazon provides excellent documentation with detailed explanations of the concepts behind the service. Route 53 can be managed from the AWS console or through the Route 53 API. When using the API, you can set account level access to have a fine-grained control over domain management through the Identity Access Management API. In this article, I’m going give a quick introduction to Route 53, briefly explaining the concepts behind it.
A few advantages of Route 53 are:
- Fast: Route 53 uses Anycast with 24+ DNS servers distributed across world. Queries to your domain name will be resolved by the nearest DNS server.
- Reliable: AWS guaranties 100% availability for Route 53. Read the SLA to know more about this.
- Integration with other services: It’s designed to work closely with other services like EC2, S3, Cloudfront, etc.
- API Support: Ability to manipulate DNS is an important feature in Route 53. You can automate DNS management along with instance provisioning.
In order to manage domains in Route 53 you can create one or more hosted zones, which is the basic entity. A Hosted Zone is similar to a zone file in any other DNS system which consists of a collection of resource record sets. A record set can be a top-level domain, its subdomains, DNS records, MX records, etc. Route 53 allows almost all types of record types in a record set.
To get started, first you’ll need to register your domain with a registrar (if you haven’t already). After successfully setting up the domain name, log in to AWS console and sign up for Route 53. There are usually two use cases when planning to use Route 53 for managing domains.
1. Manage an entire domain and its subdomains
2. Mange only a subdomain
Manage an entire domain and its subdomains
To manage your domain in Route 53, create a hosted zone by giving your domain name.
When creating hosted zone for your domain, Route 53 will add two record sets by default. One is a SOA (Service Of Authority) record and the second one is a NS record with four virtual name servers. You need to update your registrar with these name servers, so that they should answer DNS queries for your domain. Next you need to create an A-record for your root domain. As A-records can only be pointed to an IP address, you will need create an elastic IP and attach it to an EC2 instance.
Creating a subdomain is just the same as above. There you can select any other record type like, CNAM, NS Record, etc.
Manage only a Subdomain
Sometimes you may only need to move a subdomain to Route 53. Procedure for this is same as above. First create a hosted zone for your subdomain (say subdomain.example.com). It will add SOA and NS records for the subdomain. Using the name server addresses, create NS records for this subdomain in your registrar account. To use this domain name, you need to create an A-record that will point to some IP addresses. Though it’s possible to create a CNAME for a subdomain, it’s not possible in this case, as CNAME is not allowed at zone apex.
Using Route 53 with ELB
One of the serious issues that many people have complained about regarding ELB is that it won’t give you an IP address to map root domain (zone apex) to your load balancer. Instead, it will give you a CNAME. But current DNS implementation limits pointing zone apex to a CNAME. In that case you will have to create a subdomain that will point to ELB CNAME and redirect root domain to this subdomain. Route 53 provides a facility to overcome this issue by using an alias for the A-record.
While creating the Record set, select A-record after entering the domain name, which will enable radio button to choose the Alias option. Select it and enter the ELB CNAME in the textbox below (which will automatically list all available aliases for you).
Latency based Multi-Region routing
Route 53 recently added latency-based multi-region routing, which will help to route requests to instances in a region with the lowest latency. It will suggest the correct region if you enter public DNS, Elastic IP, or ELB target in the Value field. AWS frequently gathers latency measurements across the network and store in their database. They process this information to calculate latency to each AWS region from the end user’s perspective.
To configure a record set with latency-based multi-region routing, click on ‘Create Record Set’. Choose Latency in Routing policy after entering Name and Value for the record set.
You can set an ID to identify the latency set within the group. After successfully setting up two or more latency record sets, Route 53 will route the requests to region with minimal latency.
Wild card subdomains
In some cases you may want to point all your subdomains to a single host or load balancer. It is usually achieved using wild card subdomains. For example, you can create a DNS record *.abc.com that points to a host 192.0.2.235. So requests to www.abc.com and sub.abc.com will resolve to this host. Creating wild card subdomain is just the same as creating any other records. Give the wild card domain name, select the record type you want and enter host name/IP or CNAME of load balancer. Route 53 allows us to create wildcard subdomains for any record type. (Keep in mind that some registrars, like GoDaddy, doesn’t allow for some record types.)
In this article we have discussed about using AWS’s DNS service Route 53 for managing your domain. Route 53 is a reliable and cost effective service for businesses as well as developers. It is particularly useful when you want to manage your infrastructure in AWS. In Route 53, requests to your domain will be resolved by a global network of DNS servers, which make it fast and reliable. AWS provides a simple and easy to use RESTful API for managing them in the command-line. So Route 53 can act as a programmable DNS for your infrastructure.
Published at DZone with permission of Shameer Cee . See the original article here.
Opinions expressed by DZone contributors are their own.