Intro

Route 53 (R53) is a highly scalable Domain Name System (DNS) service that has the following characteristics.

  • Allows for the registration of Domain Names with the Domain Registration service.
  • Can host domains via fully managed Name Servers.
  • Is a single Global service (no region selection possible).
  • Is a Globally resilient service. Data is replicated between regions, R53 will continue to operate when 1 or more regions fail.

Hosted Zone

A Hosted Zone is a fully managed Zone File hosting service with the following characteristics.

  • A Hosted Zone hosts DNS records which are referred to as recordsets.
  • Each Hosted Zone is assigned 4 DNS name servers that host the Zone File.
  • Hosted Zones can be either public or private.
  • Public zones are hosted in the AWS Public Zone and are visible from the Public Internet.
  • If enabled, VPC instances use the Route 53 resolver (Subnet +2 IP) to query both Public and Internet hosted zones
  • Private zones are linked to VPCs and are not visible from the Public Internet.
  • Private hosted zones are only accessible from the VPCs they are associated with.
  • Split-DNS is supported and allows the hosting of both Public and Private DNS for the same hostname.

Record Types

DNS has a numbr of record types that are used for different purposes. The most common types are listed below.

  • NS - Name Server (NS) records specify the Authoritative DNS servers for a domain.
  • A - Maps a domain name to an IPv4 address.
  • AAAA - Maps a domain name to an IPv6 address.
  • Alias - An Alias (A/AAA) record is an AWS specific record type that points to an AWS resource.
  • PTR - A Pointer (PTR) record maps an IP address to a domain name.
  • CNAME - Maps a canonical (alternate) name to the domain name.
  • MX - Mail Exchange (MX) records secify the Email servers for a domain.
  • TXT - Text (TXT) records allow for the addition a text related data for a domian. They are commonly use to validate domain ownership.
Important
Alias recored must be used to point to the zone apex. IE: stratuslabs.net. CNAME records are not usuable in this case.

Time To Live

The Time To Live (TTL) value signals to DNS Resolver servers how long they should locally cache a Record Type for a domain.

The TTL is altered when migrating servers to new IP addresses. Generally, you set the TTL to a low value (in seconds) prior to a migration to minimise the impact to clients.

Routing Methods

Route 53 can route DNS queries with a number of methods. The following section describes the available routing methods.

Simple Routing

Simple routing is the most basic type of routing and is used when to route requests towards a single service.

Simple routing has the following characteristics.

  • Support for 1 record per name.
  • Each record can have multiple values and all values are returned for the record when queried.
  • Health Checks are not supported.

Failover Routing

Failover routing uses a Secondary DNS record to point to an alternate host in the event that the Primary host becomes unavailable.

Failover routing has the following characteristics.

  • There are 2x DNS records setup for the host a Primary and Secondary
  • The Primary record points to the main service endpoint.
  • The Secondary record points to the backup service endpoint.
  • Failover routing uses Health Checks to determine service health.
  • If the Primary resource becomes unhealthy, the record for the Secondary resource is returned.

Multi-Value Routing

Multi-Value routing allows you to return Multiple records for a name, each having an independent health check.

The following table lists an example of the values returned from a multi-value query.

Value Type Host
www.stratuslabs.net A 198.51.100.1
www.stratuslabs.net A 198.51.100.2
www.stratuslabs.net A 198.51.100.3
www.stratuslabs.net A 198.51.100.4

Multi-Value rouing has the following characteristics.

  • Multiple records are assigned to the same name.
  • Up to 8 healthy records are returned to the client.
  • If there are more than 8 healthy records, 8 are chosen at random.
  • Each record has it's own health check.
  • Unhealthy records are not returned.
  • If a health check is not assiciated, they the record is always considered healthy.
  • The client chooses a single record to use.

Weighted Routing

Weighted routing allows you to have multiple records for a name, were each record has a weight value assigned.

The following table lists an example of weighted records.

Value Weight Type Host
www.stratuslabs.net 40 A 198.51.100.1
www.stratuslabs.net 40 A 198.51.100.2
www.stratuslabs.net 20 A 198.51.100.3
www.stratuslabs.net 0 A 198.51.100.4

Weighted routing has the following characteristics.

  • All weight values for a name are calculated into a total weight for consideration for return.
  • Each value is returned based on the percentage of its weight ie: 40%.
  • A 0 weight is never considered unless all weights are 0. Then all records are considered for return.
  • Weighted routing supports health checks.
  • If an unhealthy record is selected, then the selection process starts again.

Latency-Based Routing

Latency-Based routing allows allows you to have multiple records for a name, were each records has a Region assigned.

The following table lists an example of latency-based records.

Value Region Type Host
www.stratuslabs.net us-east-1 A 198.51.100.1
www.stratuslabs.net us-west-2 A 198.51.100.2
www.stratuslabs.net ap-southeast-2 A 198.51.100.3
www.stratuslabs.net eu-central-1 A 198.51.100.4

Latency-Based records have the following characteristics.

  • Latency-Based routing supports 1 record with the same name in each Region.
  • AWS maintains a database of latency statistics between users approximate location and AWS Regions.
  • The record with the lowest estimated latency is returned.
  • If the record is unhealthy it is not returned. The next healthy record with the lowest latency is returned.

Geolocation Routing

Geolocation routing allows you to have multiple records for a name, were each record has a Geolocation assigned.

The following table lists an example of geolocation records.

Value Location Type Host
www.stratuslabs.net California A 198.51.100.1
www.stratuslabs.net North America A 198.51.100.2
www.stratuslabs.net Australia A 198.51.100.3
www.stratuslabs.net Default A 198.51.100.4

Geolocation records can be tagged with the following location types. Records are listed from highest to lowest priority.

Type Example
State (USA Only) California
Country United States
Continent North America
Default (Optional) Catch All

Geolocation routing has the following characteristics.

  • The record returned is based on the location of the users IP address or the DNS resolvers IP address.
  • The most specific record (highest priority) is retuned.
  • If an optional default records is not defined and there is no location match, then a NO ANSWER is returned.
  • State based location is only available for the United States.

Geoproximity Routing

Returns the closest record to a user based on their geographic location. Geoproximity Routing has the following characteristics.

  • Record are tagged with an AWS Region (AWS resources) or Lattitude and Longitude coordinates (Non-AWS resources).
  • By default, the record which is closest to the user by physical distance (km) will be returned.
  • Optionally, a bias can be assigned which extends or reduces the coverage area for a record.
  • A (+) bias extends the area covered. Conversely, a (-) bias reduces the area covered.
  • Geoproximity routing is not supported for private hosted zones.

Routing Method Use Cases

The following table lists the common use cases for each routing method.

Method Use Cases
Simple Routing to a single resource.
Failover Out of band failover for error pages and/or maintenance pages.
Multi-Value Return up-to 8 healthy records at random.
Weighted Simple load-balancing.
testing new software.
Latency-Based Optimizing for performance and user experience.
Geolocation Regional Restrictions.
Language specific content.
Load-balancing across regional endpoints.
Geoproximity Route traffic based on the location of a resource closest to the user.
Optionally extend or decrease the area the resource covers.

Health Checks

Health checks are used to determine the health of resources such as web and email servers and have the following characteristics.

  • Health checks are configured by the administrator and performed by a fleet of globally distributed health checkers.
  • Health checks are associated with Route 53 records.
  • If > 18% of health checkers report that an endpoint is healthy then Route 53 considers it healthy
  • If <= 18% of health checkers report that an endpoint is healthy then Route 53 considers it unhealthy
  • Free health checks are performed in 30 second intervals. The interval can be reduced to 10 seconds with an associated cost.
  • There are 3 types of health checks: Endpoint, CloudWath Alarm or Calculated by a series of health checks.
  • Endpoints are marked as Healthy when health checks pass or Unhealthy when they fail.
  • Records marked as Unhealthy are not returned in response to queries.
  • Optionally, a CloudWatch alarm can be configured to send Failure notifications via an SNS topic.

The following table lists the Endpoint health check types and default parameters.

Type Success Condition
TCP Establish a TCP connection with the endpoint within 10 seconds.
HTTP/HTTPS Establish a TCP connection with the endpoint within 4 seconds and return a HTTP status code of 2XX or 3XX within 2 seconds.
HTTP/HTTPS response body string match All HTTP/HTTPS check conditions + the search string must appear entirely in the first 5120 bytes of the response body

Route 53 Resolver

The Route 53 Resolver answers DNS queries within a VPC, and by default is available in all VPCs.

The Route 53 Resolver has the following characteristics.

  • Runs from the Subnet + 2 IP address.
  • Automatically answers DNS queries for AWS public records, Amazon VPC-specific DNS names (ec2-192-0-2-44.compute-1.amazonaws.com), and Amazon Route 53 private hosted zones (acme.example.com).
  • Performs recursive lookups against public internet name servers for public domain names.

Route 53 Resolver Endpoints

Route 53 Resolver Endpoints allow for On-Premises resources to use the AWS VPC Resolver, and for AWS resources to use On-Premises DNS resolvers.

Route 53 Resolver Endpoints have the following characteristics.

  • Allows Hybrid DNS Architectures utilizing both AWS with On-Premises DNS resolvers.
  • Connectivity between On-Premises and an AWS VPC via a Direct Connect or Virtual Private Gateway (VPN) is required.
  • Inbound resolver endpoints allow DNS queries to a VPC from On-Premises or another VPC.
  • Outbound resolver endpoints allow DNS queries from a VPC to On-Premises or another VPC.
  • Resolver Rules are used to specify which resolver (VPC or On-Premises) is forwarded queries for each domain name.
  • Resolver Rules are applied to a VPC and can be shared between accounts.

Hybrid DNS Architectures

Hybrid DNS architectures allow for the interoperation of both AWS Route 53 resolvers and on-premises DNS resolvers. There are 2 main types of designs: with Route 53 endpoints and without Route 53 Endpoints.

Without Route 53 Endpoints

Prior to the introduction of Route 53 Endpoints, an EC2 instance was used to proxy DNS queries to/from on-premises environments.

The following diagram shows an example hybrid DNS design without interface endpoints.

blog/cloud-notes-aws-route-53/aws-hybrid-dns-without-endpoints.png

The following points describe the above diagram.

  • An AWS VPC is connected to on-premises via a Direct Connnect and/or a VPN via a Virtual Private Gateway.
  • The Route 53 resolver is enabled on the subnet +2 IP address.
  • An EC2 instance is configured as a DNS forwarder, which proxies queries between AWS and the on-premises DNS resolver.
  • A DHCP option set is applied to the VPC which is configured to use the EC2 DNS forwarder for name resolution.
  • The EC2 DNS forwarder, forwards on-premises DNS zones to the on-premises DNS resolver.
  • The on-premises DNS resolver, forwards AWS DNS zones to the EC2 DNS forwarder.
  • The EC2 DNS forwarder, forwards non on-premises zones to the Route 53 resolver.
  • Both the Route 53 and on-premises DNS resolvers forward public DNS zones to upstream DNS resolvers.

With Route 53 Endpoints

Route 53 Endpoints are a managed AWS service that come in 2 flavours: Inbound and Outbound. Endpoints are deployed into a subnet as interfaces and either receive (inbound) queries from on-premises or forward (Outbound) queries to on-premises.

The following diagram shows an example hybrid DNS design with interface endpoints.

blog/cloud-notes-aws-route-53/aws-hybrid-dns-with-endpoints.png

The following points describe the above diagram.

  • An AWS VPC is connected to on-premises via a Direct Connnect and/or a VPN via a Virtual Private Gateway.
  • The Route 53 resolver is enabled on the subnet +2 IP address.
  • VPC resources, forward DNS queries to the Route 53 resolver.
  • Inbound and Outbound Endpoints are deployed as Interfaces into a Subnet.
  • The on-premises DNS resolver, forwards AWS DNS zones to the Inbound Endpoint which forwards them to the Route 53 resolver.
  • The Outbound Endpoint is configured with Rules, whihc forward on-premises DNS zones to the on-premises DNS resolver.
  • The Route 53 resolver forwards queries for the on-premises DNS zones to the Outbound Endpoint which forwards them to the on-premises DNS resolver.
  • Both the Route 53 and on-premises DNS resolvers forward public DNS zones to upstream DNS resolvers.

DNSSEC

DNSSEC uses digital signatures based on public key cryptography to enhance authentication to DNS. To prove ownership, the owner of the DNS data adds cryptographic signing to the data.

DNSSEC with Route 53 has the following characteristics.

  • Asymmetric Public and Private Key Signing Keys (KSK) are created in the Key Management Service (KMS).
  • KMS keys MUST be created in the us-east-1 Region.
  • Public and Private Zone Signing Key (ZSK) creation and rotation is handled by Route 53 automatically.
  • The Public KSK and ZSK DNS key records are added to the Route 53 Hosted Zone.
  • The Private KSK is used to sign both the Public KSK and ZSK to create the RRSIG DNS key record.
  • Route 53 registered domains automatically add the Deligated Signer (DS) record with the Top Level Domain (TLD) server owners.
  • The CloudWatch alarms DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAttention can be enabled to DNSSEC monitoring for the domain.
  • DNSSEC validation can optionally be enabled for the VPC Route 53 resolver.
# aws
# cloud