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.
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.
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.