1. Domain Name System (DNS) and Authoritative DNS Servers

1. The Domain Name System (DNS) is a distributed database that translates human-readable domain names (e.g., www.example.com) into IP addresses (e.g., 192.0.2.1), enabling the routing of internet traffic.
2. An authoritative DNS server is a type of DNS server that stores the actual DNS records for a domain and provides definitive, authoritative answers to queries about those records, serving as the source of truth for the domain's DNS data.

2. Route 53 Key Features

1. Domain Registration: Allows to register new domain names or transfer existing ones.
2. DNS Management: Translates human-readable domain names to IP addresses for routing internet traffic.
3. High Reliability: Built for millions of requests per second with a global network for low latency and high availability.
4. Routing Policies: Supports various strategies for routing traffic:
   • Simple Routing
   • Failover Routing
   • Latency-based Routing
   • Geolocation Routing
   • Weighted Routing
   • Multi-value Answers Routing
5. Health Checks & Monitoring: Monitors resources like EC2 instances and routes traffic only to healthy endpoints.
6. Private DNS: Supports DNS resolution within a VPC via Private Hosted Zones.
7. Integration with AWS Services: Seamless integration with services like CloudFront, ELB, and S3 for optimized traffic routing.
8. Hybrid DNS Solutions for on-premises and cloud environments.

3. Route 53 Hosted Zone

A Route 53 Hosted Zone is a container for DNS records associated with a specific domain (e.g., example.com).

• It is a globally resilient DNS database, hosted across multiple DNS servers to ensure high availability.
• Hosted zones can be created either through domain registration via Route 53 or separately for custom domains.
• These zones store DNS records such as A, AAAA, MX, NS, and TXT records, which define how traffic should be routed for the domain.
• Route 53 hosted zones are authoritative for the domain they represent.

Types of Hosted Zones:

1. Public Hosted Zone: Manages DNS records for domains accessible over the public internet.
2. Private Hosted Zone: Manages DNS records that are only accessible within a specified Virtual Private Cloud (VPC).

4. DNS Records in Route 53

DNS records are the fundamental building blocks in Route 53 for managing domain names. Common types of DNS records include:

1. A Record (Address Record): A stands for Address. Maps a domain name to an IP Address(IPv4). Ex- example.com > 255.255.255.0.
2. AAAA Record: AAAA stands for Quad Address four times(128bits) the size of IPv4 addresses(32 Bits). Maps a domain name to an IPv6 address. Ex- example.com > 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
3. CNAME Record (Canonical Name): Maps one domain name (www.your-domain.com) to another domain name (yourapp.provider.com) or subdomain (test.your-domain.com).
4. MX Record (Mail Exchange): Directs email traffic to the correct mail servers.
5. TXT Record: Holds text-based information, commonly used for verification or security purposes (e.g., SPF records).
6. PTR Record: A Pointer (PTR) record resolves an IP address to a fully-qualified domain name (FQDN) as an opposite to what A record does.
7. Alias Record: Map domain to selected AWS resources, such as Amazon CloudFront distributions and Amazon S3 buckets.
8. NS Record (Name Server): Specifies authoritative DNS servers for a domain.

These records allow Route 53 to control traffic routing and domain management effectively.

5. Understanding A and AAAA DNS Records

When both A (IPv4) and AAAA (IPv6) records are present for a domain like clearfunda.com in a public hosted zone, the resolver will return both IP addresses (IPv4 and IPv6), assuming the client requesting the domain can handle both protocols. Example:

Let’s say you have the following DNS records in your public hosted zone for clearfunda.com:

1. A Record: clearfunda.com → 192.0.2.1 (IPv4 address)

2. AAAA Record: clearfunda.com → 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (IPv6 address)

   How DNS Resolution Works:

   1. When a client requests clearfunda.com, the DNS resolver first checks for available records.
   2. The resolver will return both the A (IPv4) and AAAA (IPv6) records to the client, if the client supports both protocols.
   3. IPv6-capable clients will attempt to connect using the AAAA (IPv6) address first.
   4. If the client cannot use IPv6 (e.g., it’s an IPv4-only device), it will fall back to the A (IPv4) address.

6. Understanding the Difference Between www and www.example.com in DNS A Records

1. WWW: is a relative record, and by default, it is interpreted as www.example.com when it's part of the example.com zone.
2. WWW.EXAMPLE.COM: is a fully qualified record, directly referencing the FQDN.

Usage: www is typically used for DNS configuration in a domain's zone file, while www.example.com is a specific target for DNS records. Record Resolution: If you define both www and www.example.com as A records, they can point to different IP addresses (or the same), but they are distinct entries for the DNS resolver.

www IN A 192.0.2.1

www.example.com IN A 192.0.2.1

7. Zone Apex (Top Node)

The top node of a DNS namespace, also known as the zone apex, refers to the root of a specific DNS zone. For each hosted zone you create in Route 53, there is exactly one top node, which corresponds to the DNS name of the hosted zone itself.

1. If you create a hosted zone for example.com, the zone apex is example.com.
2. If you create a hosted zone for sub.example.com, the zone apex is sub.example.com.
3. There is only one zone apex per hosted zone, regardless of how many records exist within that zone.
4. Examples:
   1. For a hosted zone example.com, the top node is example.com.
   2. For a hosted zone myapp.example.com, the top node is myapp.example.com.

In summary, the number of top nodes in AWS Route 53 equals the number of hosted zones you've created.

8. Routing Policies

1. Simple Routing: Routes traffic to a single resource, ideal for basic setups like a web server (e.g., example.com).
2. Failover Routing: Enables active-passive failover, ensuring high availability.
3. Geolocation Routing: Routes traffic based on user location. Useful for region-specific content.
4. Geoproximity Routing: Routes traffic to the closest AWS Region based on the geographic location of the user and defined bias (you can set a bias to prioritize one region over another).
5. Latency Routing: Directs traffic to the AWS Region with the lowest latency.
6. IP-Based Routing: Routes traffic based on the IP address origin of users.
7. Multivalue Answer Routing: Returns up to 8 healthy records randomly, useful for load balancing.
8. Weighted Routing: Distributes traffic to resources based on weights you define, ideal for traffic proportioning.

Note:: Active-Passive Failover means that one resource is designated as "active", handling all traffic during normal operations, while another resource remains "passive" (or on standby). The passive resource only takes over if the active one becomes unhealthy or unavailable.

9. Geolocation Routing vs Geoproximity Routing

1. Geolocation Routing

1. Routes traffic based on the exact geographic location of the user — such as country, state, or continent.
2. Static configuration: You cannot adjust or shift the geographic boundaries dynamically.
3. Not suitable when you want to dynamically expand or shrink the area from which traffic is routed.
4. Use Case: All users from India go to Server A, and users from the US go to Server B.

2. Geoproximity Routing (Only available via Route 53 Traffic Flow)

1. Routes traffic based on the geographic proximity of the user to AWS resources (like an EC2 instance or ELB).
2. Dynamic control: You can adjust the size of the routing region by applying a bias.
3. Positive bias → expands traffic region.
4. Negative bias → shrinks traffic region.
5. Ideal for load distribution or shifting traffic gradually between AWS regions.

10. UDP Support and Handling DNS Failover

Route 53 supports UDP

1. Route 53 fully supports both UDP and TCP for transport protocol for DNS globally.
2. UDP (User Datagram Protocol) is the default transport protocol used for DNS queries.
3. Standard DNS queries (A, AAAA, CNAME, etc.) are typically served over UDP on port 53.
4. TCP is used as a fallback when responses are too large for a single UDP packet or for DNS zone transfers.

DNS Failover with Route 53

1. Route 53 can perform DNS-based failover using health checks.
2. You can associate health checks with primary and secondary records (e.g., active-passive failover).
3. If the primary endpoint becomes unhealthy, Route 53 routes traffic to a healthy backup.

Primary and Secondary records

1. Primary DNS Record - example.com → 192.0.2.10 (main web server)
2. Secondary DNS Record - example.com → 192.0.2.20 (backup server). This one is marked as a failover record.

11. Integration with Global Accelerator and CloudFront

Route 53 can route requests to either AWS Global Accelerator or CloudFront, depending on application's architecture and requirements.

1. Route 53 can be used to direct traffic to AWS Global Accelerator when your application requires low latency, automatic failover, and performance optimization across multiple AWS regions. Global Accelerator supports HTTP, HTTPS, TCP, and UDP protocols.
2. Route 53 is also used to route traffic to Amazon CloudFront for content delivery, caching, and low-latency access to static or dynamic web content. CloudFront supports HTTP and HTTPS protocols.
3. Beyond these integrations, Route 53 can route traffic to a wide range of AWS and non-AWS resources, including -
   1. EC2 instances
   2. Load balancers (ALB/NLB)
   3. S3 static websites
   4. On-prem servers (via IP)
   5. API Gateway endpoints
   6. External endpoints

12. Multi-layer Failover Strategies

Problem:

What if your application is running fine on Amazon EC2, but:

1. The Elastic Load Balancer (ELB) itself isn’t reachable?
2. The ELB and EC2 instances are healthy, but a bug in your application code causes the app to crash?
3. The EC2 instances in one Availability Zone of a multi-AZ ELB are experiencing issues?

Solution

Use Amazon Route 53 with a Failover Routing Policy to route traffic to an alternate region or backup resource if the primary ELB becomes unreachable. Route 53 uses a combination of mechanisms to determine the health of the ELB and the application behind it:

1. ELB Node Health: Route 53 can perform health checks directly on individual ELB endpoints to ensure the load balancer is operational.
2. Instance Health via ELB: Route 53 leverages the ELB's internal health checks to evaluate backend EC2 instance health. If all instances in the ELB fail their checks, the ELB is considered unhealthy.
3. Failover Routing: If the ELB or application fails health checks, Route 53 automatically reroutes traffic to a predefined secondary (passive) resource, such as:
   • Another region’s ELB
   • A static S3-hosted backup website
   • An on-premises IP endpoint

Note: Route 53 health checks typically monitor higher-level endpoints, such as:

• The DNS name of an ELB
• IP addresses
• Application URLs (e.g., /healthcheck)

It does not directly monitor internal application logic or individual EC2 instances unless configured explicitly.

13. Route 53 Question Example

Question 1: A social media company wants the capability to dynamically alter the size of a geographic area from which traffic is routed to a specific server resource. Which feature of Amazon Route 53 can help achieve this functionality?

Ans: Geoproximity

Explanation:

Geoproximity Routing allows to:

1. Route traffic based on the geographic location of your users and resources (e.g., AWS Regions or IP ranges).
2. Shift traffic between regions by adjusting a bias value to expand or shrink the size of the geographic region that routes to a resource.

14. Route 53 Question Example

A company has migrated its application from a monolith architecture to a microservices based architecture. The development team has updated the Amazon Route 53 simple record to point "myapp.mydomain.com" from the old Load Balancer to the new one.

The users are still not redirected to the new Load Balancer. What has gone wrong in the configuration?

1. The health checks are failing
2. The Time To Live (TTL) is still in effect
3. The CNAME Record is misconfigured
4. The Alias Record is misconfigured

Ans: The Time To Live (TTL) is still in effect.

Explanation:

In Amazon Route 53, every DNS record has a Time To Live (TTL) value, which tells DNS resolvers how long they can cache the record before checking Route 53 again for updates.

So, even if the development team updated the Route 53 record to point myapp.mydomain.com to the new Load Balancer:

1. If the old TTL value was, say, 300 seconds (5 minutes) or more,
2. DNS resolvers (including user browsers and ISPs) may still be using the cached IP of the old Load Balancer,
3. Which means users will continue being routed to the old infrastructure until that TTL expires.