Route 53 Unveiled: A Comprehensive Guide to Amazon’s DNS service.

Since the advent of the internet, IP addresses and domain names have been a core component of its ecosystem. You literally cannot use the internet without making use of IP addresses and domain names. Today, we intend to explore Amazon Route 53 which is a Domain Name System (DNS) service provided by AWS. If you are unfamiliar with the term Domain Name System, you are probably wondering what it is all about, so before going on to explore what Route 53 is, its features and capabilities, I’ll like us to first look at what a Domain Name System is. This will help put things into perspective when it comes to Route 53.

What is a Domain Name System?

It is a decentralized system used to translate human-friendly domain names, like example.com, into machine-readable numeric IP addresses, such as 192.0.2.1. To make you better understand what this means, let’s use an analogy: A Domain Name System is like a phonebook for the internet. Just like a phonebook helps you find the phone number associated with a person’s name, DNS helps your computer find the IP address associated with a website’s domain name. For DNS, the names are domain names (www.example.com) that are easy for people to remember and the numbers are IP addresses (192.0.2.1) that specify the location of computers on the Internet. Instead of remembering complex sequences of numbers (IP addresses) for different websites, you can simply type in a domain name (e.g., www.example.com) and the DNS translates it into the corresponding IP address so your computer can connect to the website.

A DNS service works behind the scenes, ensuring that when you enter a domain name for a website in your web browser, your request is routed to the correct IP address associated with the website you want to access. DNS servers translate requests for domain names into IP addresses, controlling which server an end user will reach when they type a domain name into their web browser. These requests are called “queries.” DNS plays a crucial role in connecting users to online resources by providing a hierarchical and distributed naming system. Now onto Route 53 proper!

What is Amazon Route 53?

Route 53 is a scalable and highly available Domain Name System, domain name registration, and health-checking web service offered by AWS. It is designed to give developers and businesses an extremely reliable and cost-effective way to route end users to Internet applications by translating domain names like example.com into the numeric IP addresses, such as 192.0.2.1, that computers use to connect to each other.

With Route 53, you can register and manage domain names, create DNS records to map domain names to IP addresses, distribute traffic across multiple resources for high availability and scalability, and perform health checks to monitor the availability of your resources. It provides advanced routing options allowing you to optimize the performance and resilience of your applications. Route 53 effectively connects user requests to infrastructure running in AWS — such as Amazon EC2 instances, Elastic Load Balancing load balancers, or Amazon S3 buckets — and can also be used to route users to infrastructure outside of AWS.

It’s time for us to explore some of the features and capabilities Route 53 offers to its users. We are going to look at Hosted Zones, Route 53 Record types and Name Servers, record TTL (time to live), and Routing policies, so let’s begin!

What are Hosted Zones?

A hosted zone is a container for records that holds information about how you want to route traffic for a specific domain and its subdomains. It is the central configuration for managing the DNS records for your domain. Think of it as a directory that stores the DNS records (more on these later) for your domain. It includes records such as A records, AAAA records, CNAME records, and more. These records define how domain names are mapped to IP addresses and determine where traffic should be directed. Route 53 offers two types of hosted zones which are, public and private hosted zones.

Public Hosted Zones contain records that specify how to route traffic on the internet. They are publicly accessible and resolve domain names to publicly routable IP addresses on the internet. They are typically used for hosting websites, web applications, or other services that need to be accessible to users worldwide. When you create a public hosted zone, you specify the domain name for which the zone will be responsible, such as example.com. You can then add DNS records within the hosted zone to map domain names to the corresponding IP addresses or other resources.

Private Hosted Zones contain records that specify how you route traffic within one or more VPCs or other private networks. Unlike public hosted zones that are accessible from the internet, private hosted zones are designed for internal use within an organization. With private hosted zones, you define custom domain names for your internal resources, such as applications, services, or databases, and map them to private IP addresses. This enables you to access these resources using user-friendly domain names within your private network, without exposing them to the public internet. Private hosted zones are associated with a specific VPC, allowing the DNS resolution to occur within the VPC’s isolated network environment. This provides several benefits, such as improved security, reduced latency, and simplified network management.

Note: Using hosted zones in Route 53 is not free. You have to pay a fee of $0.50 per month for each hosted zone you create.

Record Types

In Amazon Route 53, there are several record types available to define DNS configurations for your domain names. Each record type serves a specific purpose and provides different functionality. We are going to look at some of the commonly used ones in brief detail.

A (Address) Record: It is a DNS record that is used to map a domain name or subdomain to a static IPv4 address. An A record allows you to associate a domain or subdomain with a specific IP address, enabling users to reach your website or other resources using a domain name. A Records are crucial for directing traffic to the correct destination using domain names. They are widely used for website hosting, load balancing, and various other scenarios where associating a domain with an IPv4 address is required.

AAAA (IPv6 Address) Record: An AAAA (pronounced quad A) record is a DNS record that maps a domain name to an IPv6 address. They serve a similar purpose as A Records, but instead of IPv4 addresses, AAAA Records associate a domain or subdomain with an IPv6 address. AAAA Records are used for directing traffic to IPv6-enabled resources. With the exhaustion of IPv4 addresses, the adoption of IPv6 is becoming increasingly widespread. AAAA Records allow organizations to make their websites, applications, and services accessible to users with IPv6 connectivity.

CNAME (Canonical Name) Record: It is a type of DNS record used to map an alias or nickname to a true or canonical domain name. CNAME Records serve as an alias or nickname for a domain or subdomain and instead of pointing directly to an IP address like other record types, they point to the canonical name of another domain. They are commonly used for redirection purposes. For example, if you have multiple subdomains pointing to the same server or service, you can create CNAME Records for each subdomain, all pointing to the canonical name of the server or service. This allows you to easily update the underlying IP address or server by modifying just the canonical name in the CNAME Record.

Many people find it hard to understand the difference between CNAME records and Alias records, so let me try to explain the differences that exist between them in an easy-to-understand manner. Think of a CNAME record as a signpost or a redirect. Imagine you have a house (your domain) and you want to direct people to a different location (another domain). The CNAME record acts like a signpost that points people from your house to the other location. However, this signpost only works for subdomains like rooms within your house, not for the main entrance (apex/root domain). In the case of an Alias record, picture it as a shortcut or a direct connection. Instead of redirecting through signposts, an Alias record is like having a secret tunnel connecting your house directly to another location. This shortcut works for both subdomains and the main entrance (apex/root domain). It’s specifically designed for use with AWS resources, providing faster and seamless connections. To summarize, CNAME records redirect visitors to another domain, but they can’t be used for the apex/root domain. Alias records create direct connections to AWS resources, and they work for both subdomains and the apex/root domain.

Name Servers (NS)

Name servers refer to the servers responsible for handling DNS resolution for your domain. When you use Route 53 as your DNS service, it provides a set of name servers specific to your hosted zone. When you create a hosted zone in Route 53 for your domain, you are assigned a set of four or more name servers. These name servers are authoritative for your domain, meaning they have the information necessary to resolve the DNS queries for your domain. To make your domain use Route 53’s name servers, you need to update the name server information with your domain registrar. This involves replacing the existing name servers provided by the registrar with the Route 53 name servers. Once the name server update propagates across the DNS system, queries for your domain will be directed to the Route 53 name servers. These servers will then handle the DNS resolution, translating domain names to their corresponding IP addresses or other records.

Record TTL (Time To Live)

A record TTL refers to the length of time that a DNS record is cached by DNS resolvers or clients before requesting a fresh copy from the authoritative DNS server. The TTL value is specified in seconds and determines how long a DNS resolver should consider the record valid before checking for updates. When you create or update a DNS record in Route 53, you can set the TTL value for that record. The TTL value helps control the caching behavior of DNS resolvers and affects how quickly changes to DNS records propagate across the internet. A shorter TTL means that DNS resolvers will query the authoritative DNS servers more frequently, reducing the caching duration and allowing changes to propagate faster. However, it can also increase the load on your DNS infrastructure. Conversely, a longer TTL reduces the load on DNS infrastructure but may result in longer propagation times for DNS changes. It’s important to strike a balance when setting TTL values based on your specific requirements. For frequently changing records, such as those associated with failover scenarios, you should consider using shorter TTL values to ensure rapid updates. For more stable records, longer TTL values can help improve performance and reduce DNS query traffic. Remember that the TTL value specified in Route 53 is a recommendation to DNS resolvers, and some resolvers may choose to cache records for longer or shorter periods based on their own configuration.

Note: Route 53 does not have a default TTL for any record type. You must always specify a TTL for each record so that caching DNS resolvers can cache your DNS records to the length of time specified through the TTL.

Routing Policies

When you create a record, you choose a routing policy, which determines how Amazon Route 53 responds to queries. Route 53 offers several routing policies that determine how traffic is routed to resources based on factors such as geographic location, latency, health and even routing preference. When it comes to choosing the right routing policy, it depends on your specific requirements and the desired behavior for your DNS routing. Let’s delve into some common routing policies and their characteristics:

Simple Routing policy

This is the most basic routing policy in Route 53 and it allows you to associate a single resource record set with a domain name or subdomain. It is used for a single resource that performs a given function for your domain, for example, a web server that serves content for the example.com website. You can use simple routing to create records in a private hosted zone. The Simple Routing policy doesn’t provide any load balancing or traffic distribution mechanisms. It responds with the same resource record set for all DNS queries, effectively distributing traffic equally to the specified endpoint. This Routing policy is easy to configure and suitable for simple setups where you have a single resource to direct traffic to, such as a single web server or an application running on a specific IP address. It’s important to note that the Simple Routing policy may not be suitable for complex architectures or scenarios that require advanced traffic management, load balancing, or failover capabilities. If you have any of these as one of your requirements, consider employing the use of another type of Route 53 routing policy.

Failover Routing policy

It allows you to configure a primary resource and a secondary resource for your domain or subdomain. It is designed to handle failover scenarios, where the primary resource becomes unavailable, by automatically redirecting traffic to the secondary resource. By leveraging the Failover Routing policy, you can improve the reliability and resilience of your applications or websites by automatically redirecting traffic to a secondary resource when the primary resource becomes unavailable. Here is how it works:

1. You specify two resource record sets: one for the primary resource and another for the secondary resource. The primary resource is typically the main endpoint you want to direct traffic to, such as a primary server. The secondary resource is the backup endpoint that receives traffic only if the primary resource is unhealthy thereby making it unavailable.
2. Route 53 periodically checks the health of the primary resource using health checks. If the health check fails, indicating that the primary resource is down or experiencing issues, Route 53 automatically switches traffic to the secondary resource.
3. If the health check on the primary resource fails, Route 53 starts routing traffic to the secondary resource based on the failover configuration. This helps ensure that your application or website remains accessible even if the primary resource is unavailable.
4. Route 53 continues to monitor the health of the primary resource and automatically switches traffic back to the primary resource once it becomes healthy again.

The Failover Routing policy is a good fit for scenarios where you want to ensure high availability and fault tolerance for your application. For instance, you can use it to set up a primary web server and a backup server in a different region. If the primary server goes down, Route 53 will automatically direct traffic to the backup server thereby minimizing downtime.

Geolocation Routing policy

This routing policy allows you to route traffic to different endpoints based on the geographic location of the DNS resolver making the request. It is designed for scenarios where you want to route traffic based on the location of your users. Here it works:

1. You can create different resource record sets for specific geographic regions or countries. Each record set represents an endpoint or resource that you want to route traffic to.
2. You can define the geographic regions or countries to which each resource record set should respond. This mapping is based on the IP address of the DNS resolver querying the Route 53 service.
3. When a DNS resolver sends a query to Route 53, the query carries the resolver’s IP address. This IP address is used by Route 53 to determine the geographic location of the resolver.
4. Based on the geographic mapping rules you set up, Route 53 selects the appropriate resource record set for the resolver’s location. It then responds to the resolver with the IP address associated with that record set.

Here is an example use case for this routing policy: If you have a multilingual website or application, you can use Geolocation Routing to direct users to different language versions based on their geographic location. For example, users from France can be directed to the French version of your website, while users from Germany can be directed to the German version and users from other countries can be directed to the default version of your website which is the English version.

Geoproximity Routing policy

Geoproximity Routing is designed to route traffic based on the geographic location of the end user and the geographic location of your resources. It works by using the geographical location of the end user’s IP address and the defined locations of your resources. When a DNS query is received, Route 53 determines the location of the end-user and then directs the traffic to the nearest available resource within a specified radius or a set of prioritized regions. To set up geoproximity routing, you define geolocation configurations that include geographic regions and associate resources (such as AWS resources or IP addresses) with those regions. Each resource can have a set of associated geolocation configurations. When a DNS query is made, Route 53 checks the geographic location of the end user and calculates the distance between the end user and the available resources. It then directs the traffic to the closest available resource based on the defined rules and configurations.

Latency-based Routing policy

This Routing policy is designed to direct traffic to resources in the AWS region that provides the lowest latency to the end user. Latency-based routing is used in scenarios where you have resources in multiple AWS Regions and you want to route traffic to the region that provides the best latency. It uses latency measurements from multiple AWS regions to determine the region that can deliver the best performance. When a DNS query is received by Route 53, it checks the latency between each AWS region and the end user. It considers factors such as network congestion and geographic distance to calculate the latency. The region with the lowest latency is then selected to handle this DNS query. To use latency-based routing, you create latency records for your resources in multiple AWS Regions. These records are associated with specific AWS regions and reflect the performance of those regions in serving the traffic. It’s important to keep in mind that latency-based routing is based on latency measurements and not the physical distance between the end user and the region.

Weighted Routing policy

This routing policy lets you associate multiple resources with a single domain (example.com) or subdomain (acme.example.com) and choose how much traffic is routed to each resource. Here’s an analogy to help you better understand: Imagine you have a basket of apples that you want to share with your friends. Each friend is assigned a weight, representing how many apples they should receive. So, if you have three friends with weights of 1, 2, and 3, you would distribute the apples accordingly: give one apple to the friend with weight 1, two apples to the friend with weight 2, and three apples to the friend with weight 3. In the same way, with Weighted Routing, you create different resource record sets (like options) and assign a weight to each. The weight represents the proportion of traffic you want to send to each resource. For example, if you have two record sets with weights 1 and 2, Route 53 will send twice as much traffic to the record set with weight 2 compared to the one with weight 1. This can be useful for a variety of purposes, for example, a scenario where you want to distribute traffic unevenly among resources, such as testing new versions of a website or directing traffic to different regions or environments.

IP-based Routing policy

With IP-based routing in Route 53, you can fine-tune your DNS routing by using your understanding of your network, applications, and clients to make the best DNS routing decisions for your end users. IP-based routing gives you granular control to optimize performance or reduce network costs by uploading your data to Route 53 in the form of user-IP-to-endpoint mappings. Geolocation and latency-based routing are based on data that Route 53 collects and keeps up to date. Even though this approach works well for the majority of customers, IP-based routing offers you the additional ability to optimize routing based on specific knowledge of your customer base. For example, a global video content provider may want to route end users from a particular Internet Service Provider (ISP).

Multi-value Answer Routing policy

This Routing policy lets you configure multiple healthy resources and return multiple values, such as IP addresses for your web servers, in response to DNS queries. It’s like having multiple options and letting the client choose the best one. Here’s an analogy to help you better understand this: Imagine you’re hosting a party and you want to provide multiple food options for your beloved guests. You set up different food stations, such as a pizza station, a kebab station, and a taco station. Each station offers a different type of food. When your guests arrive, they can choose which station to visit based on their preferences. In the same way, with Multi-value Answer Routing, you create multiple resource record sets, each representing a different resource, such as IP addresses or endpoints. When Route 53 receives a DNS query, it responds with multiple IP addresses or endpoints, allowing the client to choose the most appropriate one based on its own logic. This routing policy is useful in scenarios where you want to provide redundancy or load balancing across multiple resources. It allows clients to choose the best option based on factors like availability, proximity, or any custom logic they implement.

With Multi-value Answer Routing, you should take note of the following:

• If you associate a health check with a multi-value answer record, Route 53 responds to DNS queries with the corresponding IP address only when the health check is healthy.
• If you don’t associate a health check with a multi-value answer record, Route 53 always considers the record to be healthy.
• If you have eight or fewer healthy records, Route 53 responds to all DNS queries with all the healthy records.
• When all records are unhealthy, Route 53 responds to DNS queries with up to eight unhealthy records.

Final Words

To wrap up this article, we have explored the DNS features and capabilities of Amazon Route 53. It’s been an exciting journey exploring the world of domain management, record types, and routing policies. With Route 53, you have a trusted companion that simplifies DNS management and empowers you to build resilient and highly available applications. By intelligently routing traffic, balancing workloads, and adapting to changing conditions, Route 53 ensures optimal performance for your users. So, don’t hesitate to embrace this powerful tool and unleash the full potential of your applications in the cloud. Let Route 53 be your guide on the path to DNS excellence. Happy routing!