hidekazu-konishi.com

AWS History and Timeline regarding Amazon Route 53 - Overview, Functions, Features, Summary of Updates, and Introduction

First Published: 2023-06-16
Last Updated: 2023-06-16

Last time, in the article "AWS History and Timeline regarding AWS Systems Manager - Overview, Functions, Features, Summary of Updates, and Introduction to SSM", I introduced the feature list of AWS Systems Manager (SSM), the transition of feature integration, and more.
This time, I have created a historical timeline for Amazon Route 53, which provides various related features including the Domain Name System (DNS) in the cloud.
Like before, I have compiled the major features of Amazon Route 53, along with additions and updates, into a "Current Overview, Functions, Features of Amazon Route 53".
I hope these will provide clues as to what has remained the same and what has changed, in addition to the features and concepts of each AWS service.

Background and Method of Creating Amazon Route 53 Historical Timeline

The reason I created a historical timeline for Amazon Route 53 this time is because Amazon Route 53 has provided a variety of functions such as operations through APIs, various routing, and health checks at an early stage in the history of AWS. I wanted to organize the information about Amazon Route 53 with the following approach.
  • Tracking the history of Amazon Route 53 and organizing the transition of updates
  • Summarizing the feature list and characteristics of Amazon Route 53
This timeline primarily references the following blogs and document history regarding Amazon Route 53.
There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current Amazon Route 53 and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to Amazon Route 53 features, but are representative updates that I have picked out.

Amazon Route 53 Historical Timeline (Updates from December 5, 2010)

So, from here on, I have a timeline of the features of Amazon Route 53.
The history of Amazon Route 53 exceeds 12 years at the time of writing this article, and the timeline is quite long, so please scroll faster if necessary.

* You can sort the table by clicking on the column name.
Date Summary
2010-12-05 Announcement of Amazon Route 53
2011-05-24 Amazon Route 53 becomes GA
2011-11-16 Amazon Route 53 becomes available from AWS Management Console.
2011-12-21 Alias records that support Zone Apex (Naked Domain, Root Domain) even with domain specification can now be used for Elastic Load Balancing (Classic Load Balancer).
2012-03-21 Latency records are supported, and Latency Routing Policy becomes available.
2013-02-11 Support for Health Check functionality and Failover functionality.
2013-05-30 Support for health checks of EC2 instances associated with ELB.
2013-06-11 Alias records support Amazon CloudFormation.
2013-06-26 Amazon CloudWatch supports monitoring of Amazon Route 53 health checks.
2013-08-14 Support for importing BIND format zone files
2014-01-07 Support for health check response character display
2014-02-18 Support for health check interval, failover threshold
2014-04-09 The health of health checks can now be assessed as a percentage.
2014-04-18 Support for HTTPS, port-specified health checks
2014-04-30 Support for domain-specified health checks
2014-07-02 Support for tagging health checks, obtaining health check counts
2014-07-31 Domain registration becomes available on Amazon Route 53. Support for Geolocation Routing Policy.
2014-11-05 Support for managing internal domains of VPC with private DNS, reuse of name server delegation set, and support for reasons for health check failures.
2014-11-25 Support for editing comments on hosted zones
2015-01-22 Support for internationalized domain names in Amazon Route 53 domain registration
2015-02-05 Domain contact information can now be updated from the management console
2015-02-11 Integration of Amazon Route 53 and AWS CloudTrail. Support for simplified display of daily health check status on management console. Support for creating 1-minute Amazon CloudWatch alarm simultaneously with health check creation. Tagging is now possible for zones and domains.
2015-02-26 Support for obtaining a list of hosted zones and the number of hosted zones with Amazon Route 53 API
2015-03-03 You can now configure white label name servers (vanity name servers, private name servers).
2015-09-15 Support for creating health checks whose status is determined based on the status of other health checks. Support for measuring latency of health checks. Support for updating health check dashboard.
2015-10-19 Amazon Registrar becomes ICANN accredited registrar for ".com" and ".net" top level domains (TLD). Support for privacy protection feature of ".com" and ".net" domains.
2015-12-03 Support for visual editor that can configure and associate traffic flow routing policy
2016-01-19 Alias records now support AWS Elastic Beanstalk.
2016-01-27 Support for domain registration for over 100 top-level domains (TLDs).
2016-02-23 Support for sending the hostname in the "client_hello" message during TLS negotiation for endpoints, enabling responses to HTTPS requests using SSL/TLS certificates.
2016-04-05 Support for health checks based on CloudWatch metrics, region selection for health checks. Support for alias records in private hosted zones and failovers.
2016-05-26 Support for billing reports for domain registration fees. Newly supports domain registration for .college, .consulting, .host, .name, .online, .republican, .rocks, .sucks, .trade, .website, and .uk.
2016-07-07 Support for manually extending domain registration periods (up to 10 years for generic TLDs and many country code TLDs).
2016-08-09 Support for DNSSEC with Amazon Route 53 domain registration.
2016-08-11 Alias records can now be used with Elastic Load Balancing (Application Load Balancer).
2016-08-30 Support for NAPTR record type. DNS query testing tool now available.
2016-11-21 Support for using IPv6 addresses for endpoints with health checks.
2017-04-10 Name servers associated with domain transfers to Amazon Route 53 can now be selected.
2017-06-21 Support for Multivalue Answer Routing policy for up to 8 records.
2017-08-21 Support for Certification Authority Authorization (CAA) records.
2017-09-01 Support for Geoproximity Routing Policy.
2017-09-07 Support for public DNS query logs in public hosted zones.
2017-09-11 Alias records can now be used with Elastic Load Balancing (Network Load Balancer).
2017-10-03 Amazon Route 53 becomes a HIPAA eligible service.
2017-12-05 Support for Amazon Route 53 Auto Naming API for automatic creation and deletion of DNS names for instances (later becomes AWS Cloud Map).
2018-02-06 Amazon Route 53 Auto Naming supports alias records and CNAME records.
2018-03-09 IAM managed policies added for Amazon Route 53 Auto Naming.
2018-03-13 Amazon Route 53 Auto Naming supports health checks by third-party checkers.
2018-10-18 Support for pausing health checks.
2018-11-07 The routing effect on end users by Geoproximity Routing Policy can now be visualized on a map.
2018-11-19 Amazon Route 53 Resolver, which resolves DNS names between Amazon VPC and on-premises over AWS Direct Connect and VPN connections, becomes available.
2018-11-28 Amazon Route 53 Auto Naming API becomes a part of AWS Cloud Map features.
2018-12-20 Alias records can now be used with API Gateway API and Amazon VPC interface endpoints.
2020-09-01 Resolver query logs become available in Amazon Route 53 Resolver.
2020-12-17 Amazon Route 53 Resolver supports DNSSEC signing and DNSSEC validation.
2021-03-31 Amazon Route 53 Resolver DNS Firewall, which protects outbound DNS requests from VPC, becomes available.
2021-07-27 Amazon Route 53 Application Recovery Controller, which manages and coordinates failovers with readiness checks and routing controls, becomes available.
2021-10-26 Default reverse lookup DNS rules can now be disabled and reverse lookup DNS namespace queries can be forwarded to external servers.
2022-03-16 Private hosted zones support Geolocation Routing and Latency Routing policies.
2022-06-01 IP-based Routing policy is supported.
2022-09-06 Alias records can now be used with AWS App Runner.
2022-09-21 Support for IAM policy permissions for groups of DNS record sets for public or private host zones.
2023-03-10 Amazon Route 53 Resolver endpoints support IPv6.
Amazon Route 53 has evolved over the years to offer not just general host zone and record registration functions that other DNS services provide, but also features such as health checks, failovers, and DNS routing, which control traffic by altering the return values of DNS queries based on conditions. Numerous updates have been implemented to enhance these features.
Such functions have not only allowed AWS to provide a DNS service with high affinity to its services but also enabled Disaster Recovery (DR) across the cloud, as typified by the construction of hybrid environments that failover between on-premise and AWS.
In this way, the use of Amazon Route 53's health checks, failovers, and DNS routing is not limited to AWS but can also be set up with the IP addresses of on-premise and other cloud environments, making it a highly versatile service.

Current Overview, Functions, Features of Amazon Route 53

From here, I will introduce the current list and overview of Amazon Route 53 features at the time of writing this article.
The functions of Amazon Route 53 can be broadly divided into domain management, DNS services, health checks, and resolvers.
Among these, the resolver primarily provides name resolution functionality within Amazon VPC, means for Inbound Endpoint and Outbound Endpoint to mutually resolve names between Amazon VPC and on-premises, and a DNS Firewall to control outbound DNS queries.
Also, DNS services and health checks provide DNS routing according to conditions such as failovers, related to each other.
This DNS routing can provide advanced and flexible settings for reducing downtime and improving reliability by using the Amazon Route 53 Application Recovery Controller, which offers monitoring of the prepared state of failover configurations and routing control based on specified rules.

Domain Management

Amazon Route 53 allows you to use domain management services such as domain registration (new acquisition), renewal, and transfer.
Here, I will describe the features of domain registration, renewal, and transfer on Amazon Route 53.

Domain Registration

At the time of writing this article, Amazon Route 53 domain registration supports more than 300 types of domains, including generic top-level domains (such as .com) and geographic top-level domains (such as .jp).
For information on the domains supported and the domain registration fees, please refer to the following.
Domains that you can register with Amazon Route 53
*Please note that AWS credits (coupons obtained through campaigns and promotions) cannot be used for domain registration and renewal fees on Amazon Route 53.
Domain registration requires contact information such as address, email address, and phone number, but there is also a privacy protection setting that hides contact information from WHOIS queries.
Also, typically, a domain that has been registered becomes available by setting up the name servers of the host zone, but it is also possible to register name servers other than the four name servers created in the Amazon Route 53 host zone.
In other words, a domain registered with Amazon Route 53 can be used not only with AWS services but also by setting up name servers prepared with DNS services in other clouds or on-premises.
For registered domains, it is also possible to use transfer lock to prevent unauthorized transfers to other registrars, and if supported by the TLD registry, you can also use DNSSEC (adding and removing public keys to/from the domain's TLD registry).

Domain Renewal

Normally, the domain validity period in Amazon Route 53 is one year, so it needs to be renewed every year, but you can also set it to auto-renew.
Also, if you prepay the fees, you can extend the domain validity period from one year up to ten years at the time of writing this article.
However, please note that AWS credits (coupons obtained from campaigns or promotions) cannot be used for domain registration and renewal fees on Amazon Route 53.

Domain Transfer

There are several patterns for domain transfer with Amazon Route 53.
Transferring a Domain from Another Registrar to Amazon Route 53
The following are some of the requirements for transferring a domain from another outgoing registrar to Amazon Route 53:
  • The top-level domain of the domain being transferred is supported by the recipient registrar (in this case, Amazon Route 53)
  • The domain is already registered with the outgoing registrar
  • If the domain has been transferred to the outgoing registrar, at least 60 days must have passed since the transfer
  • If the domain was restored after it expired on the outgoing registrar, at least 60 days must have passed since the restoration
  • The status code of the domain name on the outgoing registrar does not match any of the following:
    pendingDelete, pendingTransfer, redemptionPeriod, clientTransferProhibited, serverTransferProhibited
  • The domain transfer lock has been removed on the outgoing registrar
  • DNSSEC is disabled on the outgoing registrar
  • The contact information of the domain registrant on the outgoing registrar is up to date
  • For some top-level domains, changes to owner information must be completed
  • For some geographical top-level domains, the expiration date will not be automatically renewed after the transfer, so you need to extend the expiration date during the transfer to prevent it from expiring
The general outline of the transfer process is as follows:
1. Transfer your DNS service (such as host zone settings) to Amazon Route 53 or another DNS service (reproduce the settings in advance)
2. If you are using a DNS service other than Amazon Route 53, obtain the name server information
3. Obtain an authorization code from the outgoing registrar (not required for some top-level domains)
4. Request a transfer from the Amazon Route 53 console (enter the authorization code mentioned above, configure the name server of the DNS service you will use, configure privacy protection, etc.)
5. Carry out the transfer approval process from links such as the transfer request confirmation email
6. Wait for the domain transfer process to complete (generic top-level domains: up to 7 days, geographical top-level domains: up to 10 days)
7. Configure the domain in Amazon Route 53 (set up auto-renewal, transfer lock, DNSSEC, etc.)
Transferring a Domain from Amazon Route 53 to Another AWS Account
The methods for transferring a domain from the current AWS account's Amazon Route 53 to another AWS account include using the Amazon Route 53 API (AWS CLI, AWS SDK) and getting assistance from AWS support.
Here is an example of the transfer command to another AWS account using the AWS CLI.
  • Example of an AWS CLI command at the source (transfer request)
# aws route53domains transfer-domain-to-another-aws-account --domain-name [Domain to be transferred] --account-id [Recipient AWS account ID]
{
    "OperationId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
    "Password": "[Password from the result of the transfer command]"
}
  • Example of an AWS CLI command at the destination (acceptance of transfer)
# aws route53domains accept-domain-transfer-from-another-aws-account --domain-name [Domain to be transferred] --password [Password from the result of the transfer command]
Transferring a Domain from Amazon Route 53 to Another Registrar
The requirements for transferring a domain from Amazon Route 53 to another recipient registrar include the same items mentioned in "Transferring a Domain from Another Registrar to Amazon Route 53." In addition, it is necessary to check the requirements in accordance with the specifications of the recipient registrar.
The general outline of the transfer process is as follows:
1. If you are transferring the DNS service (such as host zone settings), reproduce the settings in advance on another DNS service (you can continue to use the Amazon Route 53 DNS service).
* For functions specific to Amazon Route 53, such as Alias Records, you will need to investigate how to reproduce equivalent functions on the recipient DNS service.
2. Obtain the name server information from Amazon Route 53 or the DNS service to be transferred
3. Obtain an authorization code from the Amazon Route 53 console (not required for some top-level domains)
4. Request a transfer from the recipient registrar (enter the authorization code mentioned above, configure the name server of the DNS service you will use, configure privacy protection, etc.)
5. Carry out the transfer approval process from links such as the transfer request confirmation email
6. Wait for the domain transfer process to complete (generic top-level domains: up to 7 days, geographical top-level domains: up to 10 days)
7. Configure the domain on the recipient registrar (set up auto-renewal, transfer lock, DNSSEC, etc.)

DNS Services

Host Zones

In Amazon Route 53's host zones, name servers are assigned for associating with domains, and records are created using the record types described later, for routing configurations to resources.
Amazon Route 53 allows you to use public host zones for external release and private host zones for Amazon VPC.
Public Host Zones
Public host zones create and use records in the zone by setting record types, routing policies, health checks, etc. described later.
Here, I describe the main features of the public host zone other than the record settings mentioned later.
  • Name servers and delegation sets
    When you create a public host zone, it automatically creates NS records and SOA records.
    Four name servers assigned by Amazon Route 53 for each host zone are set in the NS records.
These four name servers are called delegation sets, and you can create a reusable delegation set using the CreateReusableDelegationSet API from AWS CLI, AWS SDK, etc (as of the time of writing this article, delegation sets cannot be created from the Amazon Route 53 console).
Because reusable delegation sets can use the same four name servers for all domains used with Amazon Route 53's DNS services, they can simplify DNS service configuration tasks in Amazon Route 53, such as when using domains and subdomains across multiple AWS accounts.
Also, if the host zone and the reusable delegation set are created in the same AWS account, the host zone can use white label name servers.
While Amazon Route 53 name servers are in the domain format such as ns-0000.awsdns-00.com. (where arbitrary numbers are filled in 0000, 00), by setting up white label name servers, you can use them as subdomain names of your own domain, such as ns1.example.com..
  • Public DNS Query Logs
    Query logs for public host zones can be set for each public host zone and are stored in Amazon CloudWatch Logs.
    The format of the query log is as follows.
[log format version] [query timestamp] [host zone ID] [query name] [query type] [response code] [layer 4 protocol] [Route 53 edge location] [resolver IP address] [EDNS client subnet]
Here is an example of a query log.
1.0 2023-06-01T00:00:00Z Z0123456789ABCDEFGHI hidekazu-konishi.com AAAA NOERROR UDP XXX00-XX1 203.0.113.0 -
Private Host Zones
  • Limitations of private host zone routing policies and health checks
    Amazon Route 53's private host zones provide name resolution for private DNS queries from within Amazon VPC.
    To use a private host zone, set both enableDnsHostnames and enableDnsSupport in Amazon VPC settings to true and associate Amazon VPC with the private host zone.
    Private host zones have more restrictions on the routing policies and health checks mentioned later than public host zones.
    Specifically, geographically proximity routing policies cannot be used in private host zones.
    The situation as of the time of writing this article is shown in the following table.
Routing Policy Use in Private Host Zones Health Check Association in
Private Host Zones
Simple Routing Yes −
Failover Routing Yes Yes
Geolocation Routing Yes Yes
Geoproximity Routing Policy No No
Latency-based Routing Yes Yes
IP-based Routing Policy No No
Multivalue Answer Routing Yes Yes
Weighted Routing Yes Yes
Also, if you are using health checks to monitor the endpoints of Amazon Route 53, it does not support private IP addresses. Therefore, if you want to monitor an instance within a VPC, you need to allocate a public IP address.
On the other hand, the health checks that monitor the metric data streams of Amazon CloudWatch alarms can use the metrics of instances within a private VPC, so they can be used without assigning a public IP address.
Please refer to the routing policy, health check, and failover that will be described later for more details.
  • Split-view DNS
    Private hosted zones in Amazon Route 53 support split-view DNS.
    Split-view DNS is a setting that uses the same domain for public and private use.
    (Example: Use www.example.com for public and internal.example.com for private)
    (Example: Change the returned IP address for console.example.com for public and private use)
You can implement split-view DNS by creating a public hosted zone and a private hosted zone separately and associating the Amazon VPC with the private hosted zone.
  • Routing priority in case of overlapping namespaces
    The private DNS resolver of Amazon VPC is called Amazon Route 53 Resolver (formerly Amazon Provided DNS).
    When setting up split-view DNS and there are private and public hosted zones with overlapping namespaces, Amazon Route 53 Resolver routes traffic based on the most specific match with the requested domain name.
    Let's give a concrete example of the routing priority when the namespaces overlap in the private hosted zone and the public hosted zone.
(Example) When the namespace example.com overlaps in the private hosted zone and the public hosted zone, and a DNS query for portal.internal.example.com is requested from within Amazon VPC
  1. Amazon Route 53 Resolver searches for a match in the private hosted zone for portal.internal.example.com. If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
  2. If it does not exist, it searches for a match in the private hosted zone for internal.example.com.
    If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
  3. If it does not exist, it searches for a match in the private hosted zone for example.com.
    If a matching private hosted zone exists, it searches for a record matching the requested domain name, and if a record exists, it returns the value. If there is no matching record, it returns NXDOMAIN (non-existent domain).
  4. If there is no matching namespace in the private hosted zone, it forwards the request to the public DNS resolver.
In other words, when requesting a DNS query from within a VPC in case of overlapping namespaces, the private hosted zone will be searched before the public hosted zone.
  • Priority of Amazon Route 53 Resolver rules
    If the Amazon Route 53 Resolver rule mentioned later routes traffic to the same domain as the private hosted zone, the Amazon Route 53 Resolver rule takes precedence.
  • Private DNS query log
    Query logs of private hosted zones are obtained in the query log of Amazon Route 53 Resolver.
    For more information, please refer to the description of the resolver below.

Records

Record Types
The record types supported by Amazon Route 53 are as follows.
A, AAAA, CAA, CNAME, DS, MX, NAPTR, NS, PTR, SOA, SPF, SRV, TXT
Among these, you can select alias records in the A records, which I will explain next.
Alias Records
Alias records allow you to associate the Zone Apex, which is the top node of the DNS namespace, with the domain name of a specific AWS resource.
The Zone Apex refers to the domain name itself, which does not include hostnames such as www used in subdomains (e.g., example.com). It is also sometimes referred to as Naked Domain or Root Domain.
Although you can specify a domain as the value in a CNAME record, you cannot specify the Zone Apex.
Therefore, it is useful when associating a domain name (with a variable IP address in the background) used with AWS resources that correspond to the following alias records with your custom domain name.
  • Amazon API Gateway's custom region APIs and edge-optimized APIs
  • Amazon CloudFront distribution
  • AWS Elastic Beanstalk environment
  • ELB load balancers
  • AWS Global Accelerator
  • Amazon S3 buckets
  • Amazon VPC interface endpoints
  • Records within Amazon Route 53 hosted zones
About Evaluate Target Health
There is an item called "Evaluate target health" in the Amazon Route 53 record settings.
"Evaluate target health" is an option that you set to "Yes" or "No" to determine whether to assess the health of the AWS resource referred to by the alias record instead of the Amazon Route 53 health check.
For example, if you set "Evaluate target health" to "Yes" with the Application Load Balancer (ALB) as the target, the DNS failover judgment described later will be performed based on the result of the ALB health check.

Routing

Amazon Route 53 has a DNS routing function that changes the value returned to the source of the query depending on the conditions.
Among them, the Geolocation routing policy, Geoproximity routing policy, Latency routing policy, and IP-based routing policy adopt the EDNS0 extension protocol of DNS, and determine the location of the DNS query source using the sender network information sent by the DNS resolver supporting the edns-client-subnet extension.
For DNS queries from DNS resolvers that do not support the edns-client-subnet, the location of the DNS query source is estimated using the source IP address of the DNS resolver.
Routing Policy
  • Simple Routing Policy
    The simple routing policy sets standard DNS records without specifying any conditions for routing.
    To use simple routing, set up a simple routing policy and create a record.
    Unlike other routing policies, it doesn't allow the creation of multiple records of the same type and name based on conditions, but it allows you to specify multiple values (such as IP addresses).
    When multiple values are specified, a random value from the specified ones is returned for each request, but the health check cannot be used, so it is not possible to verify the healthiness of the resource corresponding to the returned value.
    If you want to route using health checks for multiple values, use the later mentioned multiple value answer routing policy.
    On the other hand, in simple routing policy, only one resource can be specified for alias records.
  • Failover Routing Policy
    The failover routing policy fails over from a record specified with a primary record type to a record specified with a secondary record type, based on the status of the associated health check.
    To use failover routing, create a record for the primary record type with an associated health check and a record for the secondary record type.
    If the health check status is normal, the record specified with the primary record type is returned; if the health check status is abnormal, the record specified with the secondary record type is returned.
    In failover routing policy, alias records can also be used.
  • Geolocation Routing Policy
    The geolocation routing policy routes traffic based on the geographical location (continent-specific, country-specific, or state-specific in the U.S.) of the DNS query origin.
    To use latency routing, create a record with a geolocation routing policy set for each geographical location (continent-specific, country-specific, or state-specific in the U.S.) you want to route.
    However, geolocation routing uses the location mapped to IP addresses, so some IP addresses that are not mapped to any location cannot be conditioned by geographical location.
    In geolocation routing policy, you can also create a default record to route certain IP addresses that are not mapped to any location or that do not match the conditions of any geographical location.
    When using a health check with a geolocation routing policy, it searches for a record with a normal health check status in the order of country→continent→default from the records with the same record name, type, and routing setting, and returns it.
    In geolocation routing policy, alias records can also be used.
  • Geoproximity Routing Policy
    The geoproximity routing policy routes traffic based on the geographical location of the DNS query source and the resource (the AWS region where the resource to be routed is located, or an area size adjusted by bias based on latitude and longitude).
    To use geoproximity routing, create a traffic flow using a traffic policy with a geoproximity rule set (as of the time of writing this article, it cannot be created from the record settings of the hosting zone).
    Geoproximity rules define the geographical location based on the AWS region where the resource to be routed is located or the latitude and longitude where non-AWS resources are located, and adjust the range of geographical locations that accept traffic by changing the value of the bias.
    While the geolocation routing policy routes by clearly specifying by continent, country, and state in the U.S., the geoproximity routing policy flexibly sets the geographical range across countries and adjusts the amount of traffic to accept.
    In geoproximity routing policy, alias records can also be used.
    * As of the time of writing this article, the "Geoproximity Routing Policy" is not supported in private hosted zones.
  • Latency Routing Policy
    The latency routing policy routes to the AWS region with the lowest network latency based on the traffic occurring between the end user and the AWS data center.
    To use latency routing, create a record with a latency routing policy set for each AWS region you want to route to.
    When using a health check with a latency routing policy, it searches for and returns a record in a healthy state among the records with the same record name, type, and routing settings.
    Alias records can also be used with the latency routing policy.
  • IP-based Routing Policy
    The IP-based routing policy routes traffic from the source of the query that matches the conditions by referring to the CIDR block of the IP range of the routing target pre-registered.
    To use an IP-based routing policy, register multiple CIDR blocks in the CIDR collection as CIDR locations, and create a record with an IP-based routing policy set by selecting the CIDR location to be routed from the CIDR collection.
    When routing traffic from an IP range not registered in the CIDR collection as a CIDR block, create a record by selecting the default location.
    However, the CIDR block that can be specified to the CIDR collection used for the IP-based routing policy is an IP range from /0 to /24 for IPv4 and /0 to /48 for IPv6, and /32 etc. cannot be specified.
    * As of the time of writing this article, "IP-based routing policy" is not supported in private hosted zones.
  • Multivalue Answer Routing Policy
    The multivalue answer routing policy routes by randomly returning after checking the health of multiple values (such as IP addresses) that can be set up to eight, using a health check.
    To use multivalue answer routing, register each of the multiple values to be routed in a record using a multivalue answer routing policy and specify a health check.
    * Alias records are not supported in the multivalue answer routing policy.
  • Weighted Routing Policy
    The weighted routing policy routes by distributing traffic relatively according to the weight in response to the traffic volume, by allocating a weight to each record that becomes a ratio to the total weight of all routing target records.
    To use weighted routing, create a record with a weighted routing policy set for each weight to be routed.
    When using a health check with a weighted routing policy, it searches for and returns a record in a healthy state among the records with the same record name, type, and routing settings.
    Alias records can also be used with the weighted routing policy.

Health Check

Amazon Route 53 health checks not only have high compatibility with AWS services but can also be used for external monitoring of cloud services and servers outside of AWS.

Types of Health Checks

  • Endpoint Health Checks
    Endpoint health checks are assessed based on response time and number of failures by health checkers around the world.
    If more than 18% of the health checkers deem the endpoint as healthy, the endpoint is considered healthy. On the other hand, if the percentage of health checkers considering it healthy is 18% or less, the endpoint is considered unhealthy.
    The following are the methods for health checks monitoring endpoints.
    • TCP
      This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint within 10 seconds.
    • HTTP/HTTPS
      This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint (IP address or domain) using the HTTP/HTTPS protocol within 4 seconds, and receives a response with HTTP status code 2xx or 3xx within 2 seconds after the connection.
    • HTTP/HTTPS and String Match
      This is a health check that is considered healthy if a health checker establishes a TCP connection with the endpoint (IP address or domain) using the HTTP/HTTPS protocol within 4 seconds, receives a response with HTTP status code 2xx or 3xx within 2 seconds after the connection, and then receives a response body containing the specified string within the first 5,120 bytes within an additional 2 seconds.
    * When using health checks that monitor endpoints, such as failover records for private host zones, for instances within a VPC, you need to assign a public IP address.
  • Health checks that monitor values calculated from other health checks
    Health checks that monitor values calculated from other health checks are those that form a parent-child relationship with health checks and determine healthiness based on the threshold set for the parent health check based on the total number of healthy child health checks, which can be set up to 256.
    The following can be used for healthiness judgment of health checks that monitor values calculated from other health checks.
    • At least a certain number of all the monitored child health checks are healthy
    • All monitored child health checks are healthy
    • At least one of all the monitored child health checks is healthy
  • Health checks monitoring the metrics data stream of Amazon CloudWatch Alarms
    You can create a health check that selects an alarm created in Amazon CloudWatch and determines healthiness based on the metrics data stream used in the alarm.
    What to note is that this health check uses the metrics data stream monitored by the Amazon CloudWatch Alarm for healthiness judgment, not the result of the Amazon CloudWatch Alarm. That is, this health check detects anomalies without waiting for the result of the Amazon CloudWatch Alarm to become ALARM state.
    Since the metrics data stream of Amazon CloudWatch is used, it can monitor without assigning a public IP address to instances within a VPC, even when setting failover records for private host zones.

DNS Failover

Amazon Route 53's DNS failover is configured by combining the aforementioned routing policy and health checks (including the Evaluate target health setting for alias records).
If a health check or the Evaluate target health setting in an alias record is set, DNS failover will be conducted in the following sequence:
  1. Select a record with high priority according to the routing policy
  2. If the Evaluate target health of the selected record is Yes through a health check or an alias record, the status of the AWS resource referred to is used to determine its health
  3. If the health of the selected record is normal, return the corresponding record value
  4. If the health of the selected record is abnormal, select the record with the next highest priority according to the routing policy and return to step 2
  5. If the health of the selected record is abnormal and there is no record to select next according to the routing policy, return the value of the last selected record
Note, If there is no health check and the Evaluate target health setting in an alias record is set to No, the selected record according to the routing policy will be returned without determining its health.

Resolver

Amazon Route 53 Resolver

The Amazon Route 53 Resolver is a DNS server that provides the functionality of both a forwarder and a full-service resolver created in the Amazon VPC.
Before the announcement of the Amazon Route 53 Resolver, it was known as the Amazon Provided DNS, supporting only private name resolution within the Amazon VPC.
When an Amazon VPC is created, the default Amazon Route 53 Resolver that is automatically created associates with a DNS server on a reserved IP address, which is the VPC network address plus 2 (for example, if it's 10.0.0.0/16, it would be 10.0.0.2). This functionality corresponds to the former Amazon Provided DNS.
In addition, The Amazon Route 53 Resolver provides inbound and outbound endpoints for name resolution via DNS queries between resolvers located in the Amazon VPC and other networks such as on-premise or other VPCs (hereafter referred to as target networks).
When creating these endpoints, you must assign an IP address to each endpoint and create two or more Elastic Network Interfaces (ENIs) in different Availability Zones (AZs).
Inbound Endpoint
An inbound endpoint is an endpoint for DNS resolvers in the target network to forward DNS queries to the Amazon Route 53 Resolver.
To use an inbound endpoint, the Amazon VPC where the Amazon Route 53 Resolver is located needs to be connected to the network via AWS Direct Connect or VPN.
In the DNS resolver in the target network, it is necessary to set up forwarding DNS queries containing the applicable domain name to the IP address of the inbound endpoint.
The flow of name resolution using an inbound endpoint from the target network is as follows.
  1. A client sends a DNS query with a domain name to be forwarded to the DNS resolver in the target network
  2. The DNS resolver in the target network forwards the DNS query to the IP address of the inbound endpoint
  3. The DNS query is forwarded from the inbound endpoint to the Amazon Route 53 Resolver
  4. The Amazon Route 53 Resolver retrieves the value corresponding to the domain name of the DNS query either by internal name resolution or by recursive query to the public name server
  5. The Amazon Route 53 Resolver returns the value to the inbound endpoint
  6. The inbound endpoint returns the value to the DNS resolver in the target network
  7. The DNS resolver in the target network returns the value to the client
Outbound Endpoint
An outbound endpoint is an endpoint for the Amazon Route 53 Resolver to forward DNS queries to the DNS resolver in the target network.
To use an outbound endpoint, the Amazon VPC where the Amazon Route 53 Resolver is located needs to be connected to the network via AWS Direct Connect, VPN, or NAT Gateway.
An outbound endpoint uses forwarding rules to control the domain names of queries being forwarded to the DNS resolver in the target network.
When creating forwarding rules for outbound endpoints, the following items are specified.
  • Rule name
  • Rule type (Forward or System)
    Forward: Used when forwarding DNS queries of specific domain names to the DNS resolver in the target network
    System: Used when resolving names for specific subdomains out of the specific domain names set with Forward, using Amazon Route 53 Resolver
  • Target domain name (or subdomain name)
  • Outbound endpoint
  • Amazon VPC associated with the rule (origin of the query transfer)
  • IP address of the DNS resolver in the target network (destination of the query transfer)
    *Only specified when the rule type is Forward
  • Tag
In addition to the forwarding rules for outbound endpoints, there are also auto-defined rules that the Amazon Route 53 Resolver automatically creates for responses to AWS-specific domains and others. If you create a forwarding rule with the same domain as the auto-defined rule, the forwarding rule takes precedence and the query is forwarded to the DNS resolver in the target network.
Additionally, in rule types, besides Forward and System, there is Recursive, which is automatically created under the name "Internet Resolver".
The Recursive rule type is set to perform recursive queries when a domain not existing in the forwarding rules or auto-defined rules is queried.
To avoid recursive queries by the "Internet Resolver" rule and forward all queries to the target network, you should create a rule specifying "." (dot) in the forwarding rules.

DNS Failover

To transfer all queries to the target network without recursive queries by the "Internet Resolver" rule, create a rule specifying "." (dot) in the forwarding rule.

Overview of Inbound Endpoint and Outbound Endpoint

I summarize the name resolution of the Amazon Route 53 Resolver's Inbound Endpoint and Outbound Endpoint in a diagram.
* The brown line represents name resolution from Amazon VPC to on-premise environment
* The blue line represents name resolution from the on-premise environment to the Amazon VPC via Amazon Route 53 Resolver
* The green line represents name resolution from the on-premise environment to the Internet via Amazon Route 53 Resolver

Overview of Inbound Endpoint and Outbound Endpoint
Overview of Inbound Endpoint and Outbound Endpoint

Amazon Route 53 Resolver DNS Firewall

Amazon Route 53 Resolver DNS Firewall is a DNS-level firewall that filters the destination domain name for outbound DNS queries sent from Amazon VPC via Amazon Route 53 Resolver, through a blacklist and whitelist.
As the Amazon Route 53 Resolver DNS Firewall is integrated with AWS Firewall Manager, you can deploy DNS firewall rules to multiple member account VPCs from a management account within an AWS Organizations organization.
Also, using the AWS Resource Access Manager (RAM), it is possible to share DNS Firewall rule groups between AWS accounts.
Amazon Route 53 Resolver DNS Firewall is primarily used by setting the following items:
  • Domain List
    The types of domain lists include user-managed domain lists (Owned domain lists) where users add and manage domains, and AWS-managed domain lists (AWS managed domain lists).
    You can register multiple domains in the owned domain list.
  • DNS Firewall Rules
    DNS Firewall Rules are created by associating either the Owned domain lists or the AWS managed domain lists and selecting one of the actions: ALLOW, BLOCK, ALERT.
  • DNS Firewall Rule Group
    This is a group of rules consisting of multiple DNS Firewall Rules.
    If multiple DNS firewall rules are added, you can specify the priority of application.
    The DNS Firewall Rule Group can be associated with multiple Amazon VPCs to apply rules.

Query Log

The query log of Amazon Route 53 Resolver is used in association with Amazon VPC, and records the following.
  • DNS queries and their responses that occur within Amazon VPC (including name resolution of private host zones)
  • DNS queries using inbound and outbound endpoints
  • DNS queries evaluated by Amazon Route 53 Resolver DNS Firewall rules
The query log of Amazon Route 53 Resolver can be saved or delivered to the following services.
  • CloudWatch Logs log group
  • Amazon S3 bucket
  • Kinesis Data Firehose delivery stream
The following is an example of the items and format of the query log.
{
  "version": "[Log format version (example: 1.100000)]",
  "account_id": "[AWS account ID (example: 123456789012)]",
  "region": "[Region (example: ap-northeast-1)]", 
  "vpc_id": "[VPC ID (example: vpc-12345678901234567)]",
  "query_timestamp": "[Query timestamp (example: 2023-06-01T00:00:00Z)]",
  "query_name": "[Query name (example: private.hidekazu-konishi.com.)",
  "query_type": "[Query type (example: A)]",
  "query_class": "[Query class (example: IN)]",
  "rcode": "[Response code (NOERROR)]",
  "answers": [
    {
      "Rdata": "[Response data (example: 10.0.0.10)]",
      "Type": "[Response DNS record type (example: A)]",
      "Class": "[Response class (example: IN)]"
    }
  ],
  "srcaddr": "[Query source IP address (example: 172.31.0.10)]",
  "srcport": "[Query source port (example: 52400)]",
  "transport": "[Query transmission protocol (example: UDP)",
  "srcids": {
    "instance": "[Query source resource ID (example: i-12345678901234567)]"
    or
    "resolver_endpoint": "[Query source resource ID (example: rslvr-in-123456789012345678)]"
    "resolver_network_interface": "[Query source resource ID (example: rni-12345678901234567)]"
  },
  "firewall_rule_action": "[DNS Firewall rule action (example: ALERT)]",
  "firewall_rule_group_id": "[DNS Firewall rule group ID (example: rslvr-frg-1234567890123456)]",
  "firewall_domain_list_id": "[DNS Firewall domain list ID (example: rslvr-fdl-1234567890123456)]",
}

Amazon Route 53 Application Recovery Controller (Amazon Route 53 ARC)

Amazon Route 53 Application Recovery Controller (Amazon Route 53 ARC) primarily possesses two functions: Readiness Check and Routing Control.

Readiness Check

The Readiness Check is a feature that verifies whether the settings, capacity, service limits of AWS resources that constitute an application are scaled to handle failover, and are prepared to avoid failure.
The components that make up the Readiness Check mainly include the following.
  • Cell
    A Cell is a set grouping AWS resources that can run an application independently, representing a unit that can be the primary or replica for failover.
    The boundaries between cells are typically separated by availability zones (AZ) or regions.
  • Recovery Group
    A Recovery Group is a unit that groups cells with the same configuration in two or more functional aspects, and constitutes the primary and replicas for failover.
  • Resource Set
    A Resource Set is a unit of the same function that groups multiple cells.
    For example, you can make Application Load Balancers (ALB) created in both primary and replica environments configured in multiple regions into a Resource Set.
  • Readiness Rule
    Readiness Rules are rules prepared for each AWS resource type supported by Amazon Route 53 ARC for auditing resources.
    The readiness status of each AWS resource is determined based on evaluations according to the Readiness Rules.
  • Readiness Scope
    Readiness Scope is a setting for the range to obtain information on the readiness status of recovery groups and cells within a Readiness Check (Recovery group, cell).
    It can be associated with global resources of the entire Recovery Group or with specific cells within the Recovery Group.
  • Readiness Check
    A Readiness Check is a setting for auditing AWS resources grouped by the Resource Set.
    The AWS resources subject to the Readiness Check are evaluated based on the Readiness Rules.
    By associating the Readiness Scope with the resources of the Recovery Group in the Readiness Check, you can obtain an overview of the readiness status of the Recovery Group and Cells.

Routing Control

Routing control is a feature that provides failover and traffic routing using Amazon Route 53 health checks and DNS resolution, with more detailed conditions than the conventional type.
Amazon Route 53 ARC's routing control mainly has the following features.
  • It allows for failover based on flexible conditions, such as detailed metrics and logic.
  • There are safety rules to prevent the drawbacks of automated routing processing, such as failover to unprepared replicas, settings with no routing destination, and route flapping.
  • It allows for manual overrides of safety rules to deal with recovery from maintenance or sudden condition changes.
The components that configure routing control include the following.
  • Cluster
    The cluster used in Amazon Route 53 ARC's routing control provides endpoints for performing API executions to retrieve and update the state of routing control.
    The cluster prepares endpoints redundantly in five regions. In addition, you can operate multiple control panels and routing controls in one cluster.
    Be careful, as billing occurs by the hour for the cluster.
  • Routing controls
    Routing controls regulate the traffic flow into cells ON/OFF based on the state of the routing controls, using the routing control health check for Amazon Route 53 ARC.
    The state of the routing controls can be retrieved and updated using the Amazon Route 53 Application Recovery Controller API (Route 53 ARC API) or AWS CLI.
    This allows for automatic control of traffic routing based on flexible conditions by program code logic, and manual control during maintenance.
    Although the state of the routing controls can be retrieved and changed from the AWS Management Console, the method using the Route 53 ARC API is recommended.
  • Routing control health check
    The routing control health check is a health check for Amazon Route 53 ARC associated with the routing control.
    The routing control health check is set on the DNS record set (such as failover records) of AWS resources (such as ALB) at the front of the cell.
    However, unlike traditional health checks, the status of the health check is not changed based on the state of the endpoint set, but rather, the health check's state is changed by the routing control.
    In other words, DNS records with a failover policy associated with the routing control health check failover based on the state of the routing control.
  • Control panel
    The control panel groups multiple routing controls and sets the application of safety rules mentioned later.
    For example, you can set routing controls for each ALB in multiple AZs, group them in the control panel, and apply safety rules.
  • Default control panel
    The default control panel is automatically created when creating a cluster, and it is a control panel to add all routing controls created in the cluster.
  • Safety rule
    A safety rule is a rule to prevent accidental decrease in availability due to the recovery action of routing control.
    For example, it prevents the drawbacks of automated routing processing, such as failover to unprepared replicas, settings with no routing destination, and route flapping.

Overview of Readiness Check and Routing Control

I will summarize the relationship of terms of Amazon Route 53 ARC's Readiness Check and Routing Control in an overview diagram, based on an example of a configuration consisting of ALB+Auto Scaling (Amazon EC2)+Amazon Dynamo DB (Global Table) in multi-region.

Overview of Readiness Check and Routing Control
Overview of Readiness Check and Routing Control

References:
AWS Documentation(Amazon Route 53)
AWS Documentation(Amazon Route 53 Application Recovery Controller)

Summary

In this article, I created a timeline of Amazon Route 53's history and looked at a list of Amazon Route 53's features and an overview.

Amazon Route 53 offers a wide range of features that have high affinity with AWS, in addition to covering basic DNS service features such as domain registration and hosting of public and private websites.
The ability to configure routing policies and failover features in various patterns, and the health check feature that allows for detailed settings under various conditions can be said to be major advantages of using Amazon Route 53.
In recent years, features that improve the convenience of DNS operation in AWS, such as Amazon Route 53 Resolver DNS Firewall and Amazon Route 53 Application Recovery Controller, have been introduced.
I would like to continue to watch how Amazon Route 53 will provide what kind of features in the future.

Please note that there is also a timeline of the entire AWS service history, including services other than Amazon Route 53. If you are interested, please check it out.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)

Written by Hidekazu Konishi


Copyright © Hidekazu Konishi ( hidekazu-konishi.com ) All Rights Reserved.