Amazon Route 53 and DNS Fundamentals Study Guide

DNS Essentials and Hierarchical Structure

• The Domain Name System (DNS) is the mechanism used to translate human-friendly hostnames, such as www.google.com, into machine-readable IP addresses, such as $172.217.18.36$.

• The DNS hierarchy is structured as follows:

  • Root Server: Represented by a dot (.), this is the top level of the hierarchy and is managed by the Internet Assigned Numbers Authority (IANA).

  • Top Level Domain (TLD): These are high-level extensions such as .com, .org, and .gov. These are managed by the Internet Corporation for Assigned Names and Numbers (ICANN).

  • Second Level Domain (SLD): This is the main name of the domain, such as google.com or aws.com. These are typically managed by domain registrars.

  • Subdomain: These are prefixes added to the SLD, such as api.google.com or www.aws.com.

  • Fully Qualified Domain Name (FQDN): The complete hostname ending at the root, for example: api.www.example.com..

• The Resolution Process: When a client initiates a request, the flow generally follows this path: Client → Local DNS Server → Root Server → TLD Server → SLD/Authoritative Server → Final IP address returned to the client.

Amazon Route 53 Core Concepts

• Service Level Agreement (SLA): Route 53 is the only AWS service that provides a $100\%$ availability SLA.

• Naming Origin: The "53" in Route 53 refers to standard DNS port $53$.

• Authoritative DNS: This is a highly available and scalable service where users manage their own DNS records.

• Domain Registrar: A service that allows users to buy and register domain names directly (e.g., Amazon Registrar).

  • Users can purchase a domain from a third-party registrar (such as GoDaddy) and point its Name Server (NS) records to Route 53 to manage DNS there.

• Hosted Zones: These are containers for DNS records. The cost for a hosted zone is $0.50$ USD per month per zone.

  • Public Hosted Zone: Used to route internet traffic to public domain names.

  • Private Hosted Zone: Used to route internal traffic within one or more assigned Virtual Private Clouds (VPCs), such as app.company.internal.

• Time To Live (TTL): This defines how long DNS resolvers cache a record.

  • High TTL (e.g., $24$ hours): Results in less Route 53 traffic and lower costs, but changes to records take longer to propagate across the internet.

  • Low TTL (e.g., $60$ seconds): Allows for faster record updates but results in a higher query volume and higher costs.

  • TTL is mandatory for all DNS records except for Alias records.

Essential DNS and Route 53 Record Types

• A Record: Maps a hostname to an IPv4 address (e.g., example.com → 1.2.3.4).

• AAAA Record: Maps a hostname to an IPv6 address (e.g., example.com → 2001:db8::1).

• CNAME (Canonical Name): Maps one hostname to another hostname (e.g., app.example.com → target.com). CNAME records cannot be created for the Root Domain (also known as the Zone Apex).

• NS (Name Server): These records direct query traffic to the specific DNS servers that are handling the hosted zone.

• ALIAS: This is an AWS-specific extension that points a hostname to AWS resources, such as Application Load Balancers (ALB), CloudFront distributions, or S3 Website endpoints.

  • ALIAS records work for both the Root Domain and Subdomains.

  • They are free of charge, automatically track IP changes of the target resource, and do not have a TTL setting.

CNAME vs. ALIAS Comparison

• CNAME:

  • Works for non-root domains only (e.g., www.domain.com).

  • Can work with non-AWS hostnames.

  • AWS charges per query for CNAME records.

• ALIAS:

  • Works for both root domains (e.g., domain.com) and non-root domains.

  • Limited to AWS resources only (cannot point directly to an EC2 DNS name).

  • Provided free of charge.

Route 53 Routing Policies

• Simple Routing Policy: Points to a single resource or returns multiple IP values in a random order. It does not support health checks.

• Weighted Routing Policy: Distributes a percentage of traffic across multiple resources based on relative weights (e.g., $70\%$ to primary, $30\%$ to secondary). This is useful for A/B testing or canary deployments. Setting a weight to $0$ stops traffic to that resource.

• Failover Routing Policy (Active-Passive): Uses a primary record backed by a mandatory health check. It routes traffic to a secondary disaster recovery record if the primary resource fails.

• Latency-based Routing Policy: Redirects users to the AWS region that provides the lowest network latency for their specific location.

• Geolocation Routing Policy: Routes traffic based on the user's physical geographic location, including Continent, Country, or US State. This is optimal for content localization or adhering to legal restrictions. A "Default" record should be included for users who do not match any specified locations.

• Geoproximity Routing Policy: Routes traffic based on both user location and resource location. It uses Bias values ranging from $-99$ to $+99$ to manually expand or shrink the coverage area of a region. This policy requires the use of Route 53 Traffic Flow.

• IP-based Routing Policy: Routes traffic based on user client CIDR blocks, mapping specific ISP subnet ranges to designated endpoints.

• Multi-Value Answer Routing Policy: Returns up to $8$ healthy records chosen randomly to provide high availability. Unlike the Simple policy, this supports health checks. It is not intended as a replacement for an Elastic Load Balancer (ELB).

Route 53 Health Checks

• Endpoint Checks: Approximately $15$ global health checkers evaluate public endpoints via HTTP, HTTPS, or TCP.

  • A target is marked as "Healthy" if more than $18\%$ of heath checkers receive a successful response (HTTP status codes $2xx$ or $3xx$).

  • The default interval is $30$ seconds, or a "fast" interval of $10$ seconds.

• Calculated Health Checks: These combine up to $256$ child health checks using boolean logic (AND, OR, NOT). This is particularly useful for managing maintenance windows.

• CloudWatch Alarm Integration: Evaluates CloudWatch alarms, such as those monitoring RDS storage or DynamoDB throttling.

  • This integration is required for Private Hosted Zones because Route 53's external health checkers cannot access private VPC endpoints.

Route 53 Resolver (Hybrid DNS)

• Used to integrate on-premises DNS infrastructure with AWS Route 53 via a VPN or AWS Direct Connect (DX).

• Inbound Endpoints: Allow on-premises DNS servers to query Route 53 to resolve AWS resources such as EC2 instances or Private Hosted Zones.

• Outbound Endpoints: Allow Route 53 to forward queries it cannot resolve back to on-premises DNS servers (e.g., resolving web.onpremise.private).