Route 53 DNS — Public, Private, and Hybrid Architectures

DNS on ANS-C01 is the load-bearing pillar of every global architecture, and Route 53 is far more than a name-to-IP lookup service — it is a programmable traffic-steering platform that the Specialty exam expects you to wield like an instrument. A representative question describes a globally distributed application with regional ALBs in five regions, a need for latency-based routing as the default plus failover to a nearer region when the latency-best region is unhealthy plus geolocation-based override for a regulatory exclusion zone plus weighted blue-green deployment within each region — and asks which combination of Route 53 features express this in 60 seconds. That is a design problem that pulls in public hosted zones, all seven routing policies, alias records, health checks (endpoint, calculated, CloudWatch alarm), traffic policies as the composer, DNSSEC for integrity, and query logging for observability — and ANS-C01 routinely tests every one of those constructs inside a single five-line scenario.

This topic is Domain 1 (Network Design, 30 percent of the exam) Task Statement 1.2 in its entirety. The official ANS-C01 exam guide lists the knowledge bullets verbatim: "DNS protocol", "DNS logging and monitoring", "Amazon Route 53 features (alias records, traffic policies, resolvers, health checks)", "Integration of Route 53 with other AWS networking services", "Integration of Route 53 with hybrid, multi-account, and multi-Region options", and "Domain registration". Roughly 6 to 9 of the 65 exam questions touch this territory.

Why Route 53 Is the Cornerstone of ANS-C01 Domain 1

DNS is where the global architecture meets the user. Every other Domain 1 topic — load balancers, edge services, hybrid connectivity — depends on DNS for client-side resolution. If DNS routes the user to the wrong region, the most carefully designed ALB and the fastest CloudFront cache are wasted. The Specialty exam tests Route 53 because Network Engineers in the field own DNS as a first-class system and the Specialty certification distinguishes a Network Engineer from a generalist Solutions Architect.

The mental model the exam rewards is Route 53 as a programmable global traffic-management plane, not just a flat name-to-IP database. Routing policies compose with health checks; health checks compose with traffic policies; traffic policies compose with DNSSEC and query logging. ANS-C01 will reward this layered thinking with full-credit answers; candidates who think of Route 53 as "just DNS" will be punished on routing-policy distractors.

Plain-Language Explanation: Route 53 DNS Design

Route 53 combines DNS protocol mechanics, AWS-specific features (alias, traffic policies, health checks), seven routing policies, hybrid Resolver endpoints, and DNSSEC. Three analogies anchor the moving parts.

Analogy 1: The Postal System With a Smart Sorting Office

Think of Route 53 as a national postal system. A hosted zone is the city's mailing list directory — every recipient (domain) registered with their delivery address (IP). A public hosted zone is the published phone book anyone can look up; a private hosted zone is the internal company directory only employees inside the office (VPCs) can read. A records are direct addresses ("123 Main St"); CNAME records are forwarding addresses ("Forward all mail addressed to John to his new address at 456 Oak St"); alias records are smart forwarding that AWS-managed (the post office knows your forwarding chain and updates automatically without TTL drift). The TTL is the expiration date on the address card — recipients cache the address for that long before re-asking. Routing policies are the smart sorting office rules: simple is "deliver to whoever is on the card", weighted is "65% to address A, 35% to address B for blue-green testing", latency is "deliver to the nearest sorting depot", failover is "if depot A is closed, redirect to depot B", geolocation is "European customers go to European depot", geoproximity is "European depot but with a 30% weight bias toward Asian depot", multi-value is "give the customer 8 different valid addresses to round-robin", IP-based is "VIP customers get the express depot". Health checks are the automated phone calls every 30 seconds to confirm the depot is still operating; if calls fail, the sorting office removes that depot from the candidate list. Traffic policies are the visual flowchart editor for composing nested rules. DNSSEC is the tamper-evident wax seal on every directory entry — recipients can verify the post office signed the address.

Analogy 2: The Restaurant Reservation System

A domain is a restaurant chain brand (e.g. "BurgerCorp"). The hosted zone is the central reservation database. NS records are the list of restaurant phone numbers for the brand — when a customer calls 411 to find a BurgerCorp number, the operator returns these. A records are the specific restaurant address ("our downtown branch is at 100 Pine St"). Alias records are AWS-aware — they point to AWS resources (ALB, CloudFront, S3 website) and AWS auto-resolves the underlying IP, even if it changes — like saying "send the customer to whichever location has the shortest line". CNAME is a forwarding number — "BurgerCorp downtown is forwarding to BurgerCorp uptown today". Latency-based routing is the call routing that connects customers to the nearest available restaurant by ZIP-code lookup. Geolocation routing is the cultural-localization rule that always sends German customers to the German-menu restaurant regardless of distance. Failover is the automated alternate that routes to another branch if the primary is closed. Weighted routing is the A/B menu test sending 90% of customers to the standard menu and 10% to the new menu. Multi-value answer is giving the customer 4 different restaurant phone numbers so their phone can dial any one (basic round-robin DNS). Health checks are the mystery shopper confirming each branch is open and serving correctly.

Analogy 3: The Air Traffic Control Tower

DNS is air traffic control. The hosted zone is the flight plan database every aircraft (client) consults. A records are direct destinations ("Flight LAX-to-JFK terminal 8 gate 23"). Alias records are dynamic gate assignments managed by the airport. CNAME is "the original gate is full, taxi to the alternate gate". Latency-based routing is the closest-airport-by-flight-time assignment. Geolocation is the regulatory-jurisdiction rule (EU flights must land at EU-customs airports). Failover is the diversion airport when the primary is fogged in. Health checks are the constant ATC pings confirming each tower is responsive. DNSSEC is the encrypted authentication on the ATC handshake — pilots can verify the tower is real and not a spoof. Traffic policies are the flight-plan composer that combines all of these rules into a single decision tree.

DNS Protocol Essentials — Records, TTL, and Negative Caching

DNS is a hierarchical, distributed, cached protocol. Route 53 implements it at scale, but the protocol fundamentals (record types, TTL semantics, negative caching, zone delegation) are exam-testable on their own.

Record types you must know

• A — IPv4 address (4 bytes, "1.2.3.4").
• AAAA — IPv6 address (16 bytes).
• CNAME — canonical name (alias to another DNS name); cannot exist at zone apex.
• MX — mail exchanger (with priority); used for SMTP routing.
• TXT — text record (used for SPF, DKIM, domain verification).
• NS — name server (lists authoritative DNS servers for a zone).
• SOA — start of authority (zone metadata, serial number, refresh/retry/expire/minimum-TTL).
• PTR — reverse DNS (IP-to-name); rarely managed in Route 53 public zones.
• CAA — certification authority authorization (which CAs can issue certificates for the domain).
• ALIAS (Route 53-specific) — alias to AWS resources; behaves like A/AAAA but auto-tracks the resource's IP.

TTL and propagation

The TTL (Time To Live) is the number of seconds a resolver caches the record before re-asking. Lower TTLs mean faster propagation but higher query load on Route 53; higher TTLs reduce cost but slow down failover. Common defaults: 300 seconds (5 minutes) for steady-state; 60 seconds when active failover is needed.

Negative caching is the resolver-side cache of "this record does not exist" (NXDOMAIN response). Controlled by the SOA record's minimum TTL field, negative caching means a misspelled DNS name will continue to fail-fast for the negative cache duration even after you create the record.

Zone delegation and NS records

A parent zone (e.g. .com) delegates to a child zone (e.g. example.com) by placing NS records for the child in the parent zone. The child zone's authoritative nameservers are listed. Resolvers traverse the chain — root zone → TLD zone → second-level zone — reaching the authoritative answer.

When you create a Route 53 public hosted zone, AWS assigns four NS records (one each from four different distinct AWS DNS resolvers globally). You must update your domain registrar's NS records to point to these four — this is the "delegation" step.

Public Hosted Zones — Domain Registration and Delegation

A public hosted zone in Route 53 is a container for DNS records that resolve from the public internet. It is the AWS equivalent of running BIND, NSD, or PowerDNS for your public domain.

Domain registration

Route 53 also operates a registrar — you can buy domains directly. The registrar pays the registry fee (e.g. Verisign for .com), handles WHOIS, and creates the hosted zone with default NS records. You can also use a third-party registrar (GoDaddy, Namecheap) and point its NS records at Route 53 — the result is identical, just split across two providers.

Glue records and out-of-zone NS

Route 53's NS records use AWS-owned names like ns-1234.awsdns-12.org. The TLD zone provides glue records (A records for the AWS NS hostnames) so resolvers don't loop. This is invisible to most operators but Network Engineers should understand the mechanism.

Apex zone constraint

The zone apex (e.g. example.com itself, not www.example.com) cannot have a CNAME. RFC 1034 forbids it because a CNAME at apex would conflict with the implicit NS and SOA records. Route 53 solves this with alias records — alias at apex pointing to an ALB, CloudFront, S3 website, or other AWS resource is the canonical pattern. Standard CNAME is only valid at sub-domains.

Private Hosted Zones — Split-Horizon and VPC Association

A private hosted zone (PHZ) is a container for DNS records that resolve only from associated VPCs — invisible to the public internet. PHZ is the AWS-managed alternative to running on-prem internal DNS, and is the SCS-C02 / ANS-C01 sanctioned pattern for VPC-internal naming.

VPC association

A PHZ is associated with one or more VPCs in any AWS account. Resources inside the associated VPCs query the AmazonProvidedDNS resolver (the .2 address in each subnet); the resolver consults the PHZ first, then falls back to public DNS for non-PHZ names.

Cross-account PHZ association

A PHZ in account A can be associated with VPCs in account B by creating an authorization in account A and association in account B (two-step API). This is the multi-account DNS pattern.

Split-horizon DNS

The same domain name (e.g. api.example.com) can resolve to different IPs depending on the resolver. Public hosted zone returns the public IP for internet clients; private hosted zone returns a private RFC 1918 IP for VPC clients. The PHZ takes precedence for VPC-resolver queries because of the resolver's lookup order. This is the canonical "internal API endpoint" pattern.

Conditional forwarding from on-premises

Hybrid DNS (covered in detail in the Route 53 Resolver — Hybrid DNS topic) extends PHZ resolution to on-premises clients via Resolver inbound endpoints. On-prem DNS server has a conditional-forward rule: "for internal.aws.example.com, forward to AWS Resolver inbound endpoint IP". The inbound endpoint sees the on-prem query, hands it to the VPC resolver, which consults the PHZ and returns the private IP.

Alias Records vs CNAME — The Most-Tested Pair

The distinction between alias and CNAME is one of the most frequently tested ANS-C01 pairs. Both forward to another DNS name, but they have different constraints, costs, and use cases.

Standard CNAME

A CNAME points one DNS name to another. Resolvers follow the chain to the final A/AAAA record. Constraints: cannot exist at zone apex, must not coexist with other records of the same name (e.g. cannot have CNAME and TXT at the same name). Charged per query (Route 53 pricing).

Alias record (Route 53 only)

An alias record is an AWS-specific extension that points to AWS resources by name. Constraints: target must be an AWS resource (ALB, NLB, CloudFront distribution, S3 website, API Gateway, Elastic Beanstalk environment, VPC interface endpoint, Global Accelerator, or another Route 53 record in the same zone). Benefits: no charge for alias queries (Route 53 absorbs the cost), can exist at zone apex, integrates with health checks for failover routing.

Health-check integration

A alias record can have an "Evaluate Target Health" flag — if enabled, Route 53 considers the target's health (e.g. an ALB's instance health) when answering queries. A standard CNAME cannot do this — health checks on CNAMEs require explicit health-check resources.

Routing Policies — All Seven Types

Route 53 supports seven distinct routing policies. Each addresses a specific traffic-management requirement, and ANS-C01 expects you to map scenarios to policies in 30 seconds.

Simple routing

Single record, single answer (or multi-value at the resolver level if the record contains multiple values, but Route 53 returns all of them). Default and simplest. No health-check integration on the record itself (only on the alias's Evaluate Target Health). Use for static one-target DNS.

Weighted routing

Multiple records with the same name, each with a weight (0–255). Route 53 returns each record proportionally to weight. Used for A/B testing, blue-green deployments, gradual traffic migration. Weight 0 sends no traffic to that record (useful for graceful drain).

Latency-based routing

Multiple records, each tagged with a region. Route 53 returns the record with the lowest network latency to the resolver. Latency data is measured by AWS continuously between regions and resolver IPs.

Failover routing

Two records — primary and secondary. Health-check on the primary; if healthy, primary is returned. If unhealthy, secondary is returned. Active-passive failover pattern. Combined with health-check evaluation for full reliability.

Geolocation routing

Multiple records, each tagged with a continent, country, or US state. Route 53 returns the record matching the resolver's location. Default record (no location filter) catches everything not explicitly matched. Used for regulatory compliance (EU users → EU servers) and content localization.

Geoproximity routing (Traffic Flow only)

Like geolocation but with bias — you can shift traffic toward or away from a region by a percentage. Only available via traffic policies (not as a standalone record). Used for fine-grained traffic shaping during disaster scenarios or capacity rebalancing.

Multi-value answer routing

Multiple records (up to 8), each with optional health check. Route 53 returns all healthy records (up to 8), and the resolver picks one. Resembles round-robin DNS but with health-check filtering. Used for resilience without a load balancer.

IP-based routing

Multiple records, each tagged with one or more CIDR blocks. Route 53 returns the record matching the resolver's IP. Used for explicit per-ISP or per-customer routing. Newer feature, less commonly tested but in scope.

Health Checks — Endpoint, Calculated, and CloudWatch Alarm

Route 53 health checks are the integrity layer beneath routing policies. Three types exist.

Endpoint health checks

Periodically (every 10 or 30 seconds) sends HTTP, HTTPS, TCP, or HTTPS-with-SNI requests to a target endpoint. Pass/fail based on response code or TCP connection success. Failure threshold (e.g. 3 consecutive failures) determines health state.

Endpoint checks come from 15+ AWS health-check locations globally. Each location independently evaluates; the overall health is "fail if 18% or more of locations fail" by default. Tunable via Service Quotas.

Calculated health checks

Combines up to 256 child health checks with AND/OR logic. Pass if N out of N children pass. Used for "this region is healthy if ALB is healthy AND RDS is healthy AND DNS resolver is healthy".

CloudWatch alarm health checks

The health-check state mirrors a CloudWatch alarm. Pass when alarm is OK; fail when alarm is in ALARM. Used for "this region is healthy if our SLO error rate is below 1%" — based on application-level metrics rather than network reachability.

Health-check evaluation in alias records

Alias records can use the Evaluate Target Health flag to consider the target's intrinsic health (e.g. ALB instance count, instance health). This is free (no separate health-check resource needed) but only works for AWS-resource targets.

DNSSEC — Cryptographic Authentication of DNS

DNSSEC (DNS Security Extensions) signs DNS responses with cryptographic keys, allowing resolvers to detect tampering. Route 53 supports DNSSEC signing for public hosted zones using AWS KMS asymmetric keys.

How DNSSEC works

The hosted zone owner generates a Key-Signing Key (KSK) stored in KMS as an asymmetric key. The KSK signs the Zone-Signing Key (ZSK), which signs all records in the zone. The KSK's public part is published as a DS (Delegation Signer) record in the parent zone, anchoring trust.

Resolvers walking the DNS chain verify each signature; if any check fails, the response is discarded. This prevents cache poisoning, on-path tampering, and BGP-hijack-based DNS spoofing.

Enabling DNSSEC on Route 53

Enable on a public hosted zone via console or API. Route 53 generates the KSK (KMS asymmetric key with ECC_NIST_P256 algorithm), signs records automatically, and exposes the DS record for upload to the registrar. Once the registrar publishes the DS record, the chain of trust is anchored.

Key rotation

KSK rotation requires updating the DS record at the registrar — a non-zero risk operation. AWS recommends rotation every 1–2 years and provides a documented rolling rotation procedure. ZSK rotation is automatic and frequent (no DS record changes needed).

Traffic Policies — Visual Composer for Complex Routing

Traffic policies are Route 53's visual flowchart editor for composing multi-step routing decisions. A policy is a directed graph of rules (geolocation, latency, weighted, multi-value, failover, geoproximity) that produces a final answer for each query.

Why traffic policies exist

Without traffic policies, expressing "latency-based with regional failover and 10% blue-green within each region" requires nested record sets that are error-prone to create manually. A traffic policy expresses this as a single visual graph: top-level latency split → regional failover → weighted intra-region.

Versioning and policy records

Each policy has versioned snapshots. You create a policy record that ties the policy version to a DNS name. Updating the policy creates a new version; rolling back is a one-click revert to a prior version. This is operationally safer than hand-editing record sets.

A/B testing with traffic policies

A common pattern: blue-green canary at 1% via weighted policy, escalating to 10%, 50%, 100% over hours. The traffic policy holds the weight; updating the weight in the policy updates traffic distribution without touching the underlying records.

Query Logging — Visibility Into DNS

Query logging captures every DNS query handled by a Route 53 hosted zone, written to CloudWatch Logs. Useful for security analysis (detecting exfiltration via DNS), debugging (which clients are querying which records), and compliance.

Enabling

Configure on a public hosted zone via console or API. Route 53 publishes logs to a specified CloudWatch Log Group. Each log record contains: query name, query type, response code, edge location that handled the query, resolver IP, and protocol (UDP or TCP).

Costs and retention

Logging is free; CloudWatch Logs ingestion and storage are charged. For high-traffic zones, ingestion costs accumulate quickly — partition logs to S3 via subscription filter and use Athena for cost-effective queries.

What query logging does NOT capture

Private hosted zone queries are logged via Resolver query logs (a separate feature on the Resolver, not the hosted zone). Public hosted zone query logs only capture queries from public resolvers — internal VPC queries to public records are also captured by Resolver query logs.

Common Traps Recap — Route 53 on ANS-C01

Trap 1: CNAME at zone apex

Wrong. CNAME is forbidden at apex; use alias.

Trap 2: Alias works for non-AWS targets

Wrong. Alias only points to AWS resources or other records in the same zone.

Trap 3: Geolocation matches the resolver's IP location

Partial. Geolocation matches the resolver's IP location, not the end-user's. EDNS Client Subnet (ECS) extends visibility but not all resolvers send it. Public DNS resolvers (Google 8.8.8.8) often do send ECS, but the resolver's geolocation is what Route 53 uses if ECS is absent.

Trap 4: Failover health checks must be on the primary record

The primary record needs a health check (or alias evaluate target health flag). The secondary does not strictly need one but should for cascading failover.

Trap 5: Multi-value answer is the same as load balancing

Wrong. Multi-value returns up to 8 healthy records; the client picks one. It is round-robin DNS with health filtering, not load balancing — there is no smart distribution.

Trap 6: Traffic policies replace hosted zones

Wrong. Traffic policies create policy records inside hosted zones. Both coexist.

Trap 7: DNSSEC works without the DS record at the registrar

Wrong. Without the DS record, the chain of trust is broken and resolvers treat the zone as unsigned.

Trap 8: Route 53 health checks come from one location

Wrong. They come from 15+ AWS health-check regions globally, with majority-vote deciding overall health.

Trap 9: TTL of 0 disables caching

Partial. TTL 0 tells resolvers not to cache, but most public resolvers enforce a minimum TTL of 30–60 seconds regardless. Plan for some caching even at TTL 0.

Trap 10: Private hosted zone resolves from on-prem automatically

Wrong. PHZ resolves only from associated VPCs. On-prem resolution requires Route 53 Resolver inbound endpoints (covered in the Resolver Hybrid DNS topic).

Trap 11: Geoproximity is a routing policy at the record level

Wrong. Geoproximity is only available within traffic policies, not as a standalone policy on a record.

Trap 12: Latency-based routing accounts for application latency

Wrong. Route 53 measures network latency from resolver IP to AWS region. Application latency (slow database, slow Lambda) is invisible to Route 53.

FAQ — Route 53 on ANS-C01

Q1: When should I use weighted routing vs latency-based routing for multi-region failover?

Latency-based routing sends each user to the lowest-latency region, optimising user experience. Weighted routing sends a fixed percentage of traffic to each region, regardless of latency. For multi-region failover, latency-based plus health-check evaluation is the standard pattern: users get the nearest healthy region. Weighted is the right answer for blue-green deployments (90% to old version, 10% to new) and gradual migrations (shift weight over time). The Specialty exam will use both patterns; pick latency for "user experience" or "global reach" and weighted for "controlled rollout" or "A/B testing".

Q2: How does Route 53 health-check evaluation in alias records differ from a standalone health check?

An alias record's Evaluate Target Health flag uses AWS's intrinsic health knowledge of the target — for example, an alias to an ALB checks whether the ALB has any healthy targets registered. A standalone health check is a separate Route 53 resource that polls a custom endpoint (HTTP, HTTPS, TCP) periodically. Alias evaluation is free, AWS-managed, and instant; standalone health checks cost per check and require explicit configuration. For AWS-resource alias records, always use Evaluate Target Health. For non-AWS targets (an on-prem URL, a third-party SaaS), standalone health checks are the only option.

Q3: Why does the zone apex require alias instead of CNAME?

The DNS standard (RFC 1034) forbids CNAME at apex because the apex must coexist with the zone's mandatory NS and SOA records, and CNAME is exclusive — a name with a CNAME cannot have other record types. Alias circumvents this by behaving like an A or AAAA record at the protocol level (the resolver sees an A response with the resolved IP) while AWS internally tracks the target. So alias preserves NS/SOA at apex while delivering CNAME-like indirection. Without alias, you would have to hardcode the target's IP in an A record at apex — fragile because AWS-managed services (ALB, CloudFront) change IPs.

Q4: How does Route 53 measure latency for latency-based routing?

Route 53 maintains a continuously updated latency database measured from each resolver IP (sample) to each AWS region. Measurements are taken via internal probes between AWS edges and a sample of public DNS resolvers. The data is statistical, not real-time per query — Route 53 returns the region that is empirically lowest-latency from your resolver's network neighborhood. This means latency-based routing reflects average network latency from your ISP's resolver, not your phone's specific Wi-Fi link. ANS-C01 will reward you for recognising this — latency-based routing is not a real-time RTT measurement.

Q5: What is the difference between geolocation and geoproximity routing?

Geolocation is a discrete, exclusive match — you tag each record with a continent, country, or US state, and Route 53 returns the record matching the resolver's location exactly. There is a default record for "no match". Geoproximity is a continuous, bias-able match — Route 53 calculates the great-circle distance from resolver to the AWS region (or to a specified geographic coordinate), and you can apply a bias percentage to favor or disfavor specific regions. Geoproximity is only available in traffic policies. Use geolocation for regulatory routing (EU users → EU servers, never overridden); use geoproximity for capacity-aware routing during disasters (shift 30% of US-east traffic to US-west during a regional impairment).

Q6: How do I set up an active-passive failover across two regions?

Create two A records with the same name (e.g. api.example.com), routing policy "failover", with one as primary and one as secondary. Attach a health check to the primary's underlying endpoint (the ALB or NLB or custom URL); health-check evaluation determines whether primary is healthy. If primary is healthy, Route 53 returns the primary record; if primary fails, Route 53 returns the secondary. Use alias records with Evaluate Target Health for AWS-resource targets to avoid paying for separate health checks. Set the TTL low (60 seconds) to ensure fast resolver-side failover. Total failover time: health-check failure threshold × interval + TTL ≈ 90–180 seconds in the typical configuration. ANS-C01 will reward this exact pattern as the canonical "active-passive multi-region" answer.

Q7: Can I use Route 53 to resolve internal AWS resources from on-premises?

Yes, via Route 53 Resolver inbound endpoints. The PHZ in a VPC contains the internal records; the inbound endpoint is an ENI-backed resolver in that VPC. On-premises DNS servers are configured with conditional forwarding rules: "for internal.aws.example.com, forward queries to AWS Resolver inbound endpoint IP". Hybrid DNS resolution flows on-prem → Resolver inbound endpoint → VPC resolver → PHZ → answer. The Resolver Hybrid DNS topic covers this in detail.

Q8: What is the practical TTL recommendation for production systems?

60 seconds is the modern AWS-recommended TTL for records that need active failover capability (alias records to ALBs, primary failover records). 300 seconds (5 minutes) is fine for steady-state records that don't change frequently (CDN aliases, static sites). 86400 seconds (1 day) is fine for ultra-stable records (zone apex pointing to a corporate ALB that hasn't changed in a year) but slows DNS-based migration to a crawl. TTL 0 is rarely useful — most public resolvers enforce a 30–60 second minimum regardless. ANS-C01 will reward 60 seconds as the answer for "minimize failover time"; longer TTLs are correct for "minimize DNS query cost" scenarios.

Q9: How do I migrate a zone from a third-party DNS to Route 53 with zero downtime?

Step 1: Create the public hosted zone in Route 53 and replicate all records (use cli53 or AWS CLI for bulk import). Step 2: Verify the zone resolves correctly using dig @ns-XXX.awsdns-XX.org example.com (querying Route 53 directly). Step 3: At the registrar, update NS records to the four Route 53 NS values. Step 4: Wait for TTL of the parent zone's NS delegation (often 24 hours) for resolvers to start using Route 53. Step 5: Once Route 53 is authoritative, you can delete the records from the third-party provider. Critical: do not delete third-party records before the NS migration is fully propagated — split-brain DNS during transition is a chronic incident. ANS-C01 expects you to recognise this multi-step pattern.

Q10: Is DNSSEC mandatory for compliance, and does it affect performance?

Not always mandatory. Some regulatory regimes (US federal, certain EU sectors) require DNSSEC for .gov or government-affiliated domains. For most commercial deployments, DNSSEC is best-practice but optional. Performance impact: DNSSEC signing is server-side (Route 53 handles it); resolver-side validation adds 5–20ms per query for the first lookup, then is cached. The tradeoff is operational risk — DNSSEC misconfigurations (expired signatures, broken DS chain, wrong KSK) cause hard outages. Enable DNSSEC after thorough testing in a non-production zone first; ANS-C01 will reward "enabled DNSSEC with monitoring and alerting on validation failures" as the mature answer.

Further Reading and Related Operational Patterns

• Amazon Route 53 Developer Guide
• Working with private hosted zones
• Choosing a routing policy
• Configuring DNS failover
• How Amazon Route 53 routes traffic for your domain
• Configuring DNSSEC for a domain
• Creating a traffic policy
• Logging DNS queries

Once Route 53 public/private/hybrid DNS architecture is in place, the natural next operational layers on ANS-C01 are: Route 53 Resolver — Hybrid DNS and Conditional Forwarding for the on-prem-to-AWS bidirectional resolution; Edge Architecture — CloudFront and Global Accelerator which sit between users and ALBs and depend on DNS for client-side resolution; VPC Architecture, CIDR Design, and Subnetting for the IP plane underneath the DNS plane; and Network Monitoring, Troubleshooting, and Cost Optimization for the observability and cost-tuning layer over the entire stack.

• Route 53 Resolver — Hybrid DNS and Conditional Forwarding — ANS-C01 Study Notes
• Edge Architecture — CloudFront and Global Accelerator — ANS-C01 Study Notes
• VPC Architecture, CIDR Design, and Subnetting — ANS-C01 Study Notes
• Network Monitoring, Troubleshooting, and Cost Optimization — ANS-C01 Study Notes