Route 53 earns its name because DNS runs on port 53. Route53 is an authoritative DNS service so it will translate domain names to IP addresses. Each domain is called a hosted zone. A record set is a rule within the hosted zone. Route53 does three functions:

1. Register domain names
2. Route Internet traffic to resources
3. Check the health of your resources

Record types

Route53 Supports:

• A record - points to an IPv4; uses TTL, a time to live expressed in seconds; used for apex and maps to one or more IP addresses
• AAAA record - points to an IPv6 address
• CNAME - for use on non-apex names - CNAME can’t be used for a naked domain (zone apex); costs money
• Alias records - a free Route53 specific record type that points to an AWS resource such as CloudFront, EB, ELB, Bucket, Global Accelerator, other Route53 record set; no TTL possible
• MX records - Mail
• NS - Name servers

Triage DNS record types

• Minimize costs? Alias because it is free.
• Sub Domain? = A record or Alias record
• Any AWS service? Alias
• Zone Apex (mclaughlin.today)? Alias pointing to the resource
• Zone apex to EC2? Alias to Elastic IP URL; CNAME to IP; Why? can’t CNAME to apex; can’t Alias to IP
• ARN or other cloud resource lookup? Cloud Map (OR alias)

Domain set up

1. Create public hosted zone
2. Get NS records for hosted zone
3. Update NS values on Domain record

Routing Policy

There are 5 7 different ways for Route53 to do its thing….route. Traffic policies enable traffic flow rules IaC. Traffic Flow is a console interface that enables the creation of traffic rules visually.

• Simple - like the name says - route to an address or a bucket; have more than one address? Route53 returns all values in a random order which results in the client picking the address; Health Checks
• Weighted - a percentage to one location and a different percentage to another; expressed as a integer value relative to one or more other integer values; Health Checks
• Latency - Use the latency routing policy when you have resources in multiple Amazon EC2 data centers that perform the same function and you want Amazon Route 53 to respond to DNS queries with the resources that provide the best latency. Health Checks.
• Failover - Use the failover routing policy when you want to configure active-passive failover, in which one resource takes all traffic when it’s available and the other resource takes all traffic when the first resource isn’t available; Health Checks required.
• Geo-location - Use the geo-location routing policy when you want Amazon Route 53 based on user location; must have default record unless you want to deny geos NOT on the list; failed close scenario. Must use Route53 traffic flow.
• Geo-proximity routing - enables the ability to introduce bias to routing based on resources location AND user location; support non-AWS resources using Lat/Long. Must use Route53 traffic flow.
• Multi-value - like simple but queries return up to 8 health resources; considered healthy if there are no health checks; works in private hosted zone.

Triage Route53 Routing

• Same content multiple buckets? Latency routing
• active-passive? Fail over OR any configuration using a failover routing policy
• active-active? any routing method except failover
• Regional Fail-over? Latency based routing between regions; then do weighted resource record set between AZs with “Evaluate Target Health”
• A or B site testing? Weighted Routing
• Extend Internal DNS -> Route53? Add record set; then A record; create VPC DHCP options set with AmazonProvidedDNS and on-prem DNS server
• Share outbound resolver? use RAM.

Route53 Health Checks

Health checks can monitor an endpoint, the status of CloudWatch Metric or Alarm, OR calculate the health using more than one other health checks.

• Endpoint health checks - Can use HTTP/HTTPS or TCP; if HTTP/S can optionally read part of the response; ok if service responds with 2XX or 3XX from world-wide health check points. Only available for resources that are publicly addressable.
• Calculated health checks - checks can use boolean logic and specify a minimum # of up to 256 alarms that should be healthy (useful for deployments).

Components & Features

• Records - an A, AAAA, MX, NS, or Alias resolver statement
• Hosted zones - contains a set of records; can be public or private
• DNSSEC - verifies DNS data integrity and origin in public hosted zones; supports domain registration and signing; protects against Man-in-the-middle MITM attacks

Hybrid DNS

By default Route53 can resolve external, public zones, and private zones. Hybrid DNS must be set up to resolve AWS names from on-prem (inbound) and on-prem names from AWS (outbound). These set ups can be used by one or more VPC in the same region. Endpoints can support 10K queries per second per IP; one IP per AZ for HA.

• Inbound resolvers are not complicated. Create Route53 inbound endpoint. Simply point on-prem DNS servers to the Route53 endpoint, which is associated with 1 or more ENI in the VPC, containing the resources.
• Outbound resolvers route from the VPC through the resolver outbound end point to the on-prem NS. Conditional rules forward specified lookups to a specific IP address. System rules override conditional rules. Auto-defined rules work for private hosted zones and AWS internal domain names.

Internal DNS (Private hosted zones)

Internal Route53 DNS for a VPC is called Private Hosted Zones. For this to work the VPC must have enableDnsHostnames and enableDnsSupport enabled; when enabled Route53 uses the private IP address.

Private hosted zone have to use CloudWatch alarms or metrics for health checks because they are not accessible from outside the VPC.

Internal Route 53 resource record sets only work if the originating request is made from within the VPC. Internal Route 53 record sets cannot be extended to on-premise usage.

Sharing a private hosted zone

Private hosted zones can be shared cross-accounts via an invitation but not from the console. Steps:

1. From VPC doing the sharing, use the CLI, SDK, or Route53 API specify the hosted zone ID when making the CreateVPCAssociationAuthorization call.
2. From the account being shared with, authorize the association using the CLI, SDK, or Route53 API.
3. Optional but recommended: Delete the authorization to associate the VPC with the hosted zone.

Split-view DNS

Route53 supports split-view DNS, the ability serve different content for internal and external users using the same name. Steps:

1. Create public and private hosted zones with the same name
2. Associate the private hosted zone
3. Add records to both record sets.