Route 53 Resolver — Hybrid DNS and Conditional Forwarding

Route 53 Resolver hybrid DNS on ANS-C01 is the most-confused topic in the entire exam guide. The Solutions Architect exam treats DNS as "Route 53 hosted zones, the answers are the records". The Advanced Networking Specialty exam asks "given a multi-account org with on-premises Active Directory at corp.example.com, an AWS private hosted zone for aws.example.com associated with 12 VPCs across 3 accounts, and a separate inspection VPC where an outbound Resolver endpoint forwards specific corporate domains to on-premises, design the resolver rules, the RAM sharing, the DHCP option set, and explain how the .corp queries from a Lambda in account B reach an on-premises DC". That is hybrid resolver topology with RAM-shared rules, and ANS-C01 will ask three to five variants of this exact problem.

This topic covers the full Route 53 Resolver primitive surface: VPC default resolver at VPC+2, AmazonProvidedDNS, inbound endpoints for on-prem→AWS resolution, outbound endpoints with forward rules for AWS→on-prem resolution, the often-confused direction semantics (named from the resolver's perspective), Resolver rule sharing via AWS RAM, DHCP option sets for custom DNS server configuration, private hosted zone associations including cross-account, Route 53 Resolver DNS Firewall for domain filtering, and the canonical multi-account centralised resolver pattern. Mapped to Task Statement 2.3 (Implement complex hybrid and multi-account DNS architectures).

Why Route 53 Resolver Is the Most-Tested Topic in Domain 2

Domain 2.3 dedicates an entire task statement to "complex hybrid and multi-account DNS architectures", reflecting how operationally tricky DNS is at scale and how often AWS sees customers misconfigure it. ANS-C01 expects you to design hybrid DNS that resolves AWS-side names from on-premises, on-prem names from AWS, and multi-account-private names across the org, all without breaking each other. Expect 4-6 questions on resolver topology, conditional forwarding, RAM sharing, and DHCP option sets.

The framing across this topic is DNS as a routed service. Just as VPC routing has tables, propagation, and forwarding decisions, DNS resolution has zones, rules, and forwarding decisions. Route 53 Resolver is the AWS-managed control plane that orchestrates this — it intercepts DNS queries from VPC instances at the well-known IP VPC base + 2, applies resolver rules to decide where to send each query, and either resolves locally (private hosted zone, public DNS, .internal) or forwards to an on-premises resolver via outbound endpoint.

The exam tests resolver in three distinct flavours. Direction semantics asks "to resolve AWS names from on-prem, do you need an inbound or outbound endpoint?" (inbound — named from the resolver's side, the on-prem DNS is sending traffic into the resolver). Rule design asks "to forward corp.example.com to on-prem and resolve everything else normally, what rule do you create?" (a forward rule for corp.example.com to the on-prem IP). Multi-account sharing asks "rule must apply to 12 VPCs across 3 accounts — how?" (create rule in central account, share via RAM, member accounts associate to their VPCs).

Plain-Language Explanation: Route 53 Resolver Hybrid DNS

Route 53 Resolver combines a few primitives (default resolver, inbound endpoint, outbound endpoint, rules, DHCP options) into hybrid DNS that handles AWS-side, on-prem-side, and shared-zone resolution. Three analogies anchor the moving parts.

Analogy 1: The Phone Switchboard With Local and Long-Distance Lines

Think of Route 53 Resolver as the phone switchboard for a corporate campus. The VPC default resolver at VPC+2 is the receptionist who answers every internal call. When an employee dials a number, the receptionist either: (a) knows the number locally (private hosted zone, .internal) and routes the call directly; (b) looks it up in the public phone book (public DNS); or (c) forwards to long-distance (on-premises corporate phone system) via the outbound endpoint — the campus's outbound long-distance line. An inbound endpoint is the incoming long-distance line that lets calls from outside the campus reach the campus directory — the receptionist receives the inbound call and looks up the local extension. Forward rules are the receptionist's instructions: "for any call to extension starting with 'corp.', forward to the corporate HQ switchboard at 10.1.0.5". DHCP option sets are the master phone book given to every new employee: "your default switchboard is at extension 2; for any unrecognised area code, dial 9-1 first" — this overrides the default behaviour at provisioning time.

Analogy 2: The International Postal Sorting Office With Forwarding Agreements

A VPC is a country with its own postal system. The default resolver is the central post office that handles every letter. The post office knows: (a) local addresses (private hosted zone, .internal — like home delivery within the country); (b) international addresses via the global directory (public DNS); and (c) special forwarding agreements with neighbouring countries — for letters to specific zip codes, send to the partner post office in another country (outbound endpoint forwarding to on-premises DNS). The inbound endpoint is a post office box for foreign mail clients — letters from outside the country arrive at this box, are processed by the resolver, and a response is sent back. Forward rules are the postal agreements: "anything to 'corp.example.com' goes to partner post office at 10.1.0.5". DHCP option sets are the default mailroom procedures every new home is given: "use the central post office, search domain example.com".

Analogy 3: The Library Reference Desk With Inter-Library Loans

A VPC is a research library. The default resolver is the reference desk answering every book lookup query. The reference librarian knows: (a) books in the local stacks (private hosted zone, .internal); (b) books in the wider catalog (public DNS); and (c) special arrangements with other libraries — for books on certain topics, request via inter-library loan from a partner library (outbound endpoint forwarding). The inbound endpoint is the inter-library loan counter where partner libraries send their lookup requests — the local librarian responds. Forward rules are the inter-library loan agreements: "any title with prefix 'Corporate Standards' goes to library X". DHCP option sets are the patron orientation packet: "your default reference desk is at extension 2; search prefix 'example.com.' for ambiguous titles".

VPC Default Resolver — VPC+2 and AmazonProvidedDNS

Every VPC has a default resolver at the well-known IP base of VPC CIDR + 2. For a VPC 10.0.0.0/16, the resolver is at 10.0.0.2. This is the AmazonProvidedDNS service, automatically reachable from every instance and Lambda function in the VPC.

What the default resolver does

The default resolver answers DNS queries from VPC instances by:

1. Private hosted zone (PHZ) lookup — if the domain matches a PHZ associated with this VPC, return the PHZ records.
2. AWS-internal .internal resolution — for AWS-internal names (e.g., ip-10-0-1-5.ec2.internal).
3. Public DNS recursive lookup — for any other domain, query public DNS servers and cache the answer.

enableDnsSupport and enableDnsHostnames

Two VPC attributes control DNS:

• enableDnsSupport (default true): the VPC+2 resolver is functional.
• enableDnsHostnames (default false for VPCs created via console default; true with private DNS for default VPCs): instances launched in this VPC get auto-assigned DNS hostnames.

Both must be true for private DNS on interface endpoints to function. ANS-C01 frequently tests this.

.internal zone

AWS reserves the .internal TLD for internal hostnames. EC2 instances get auto-assigned hostnames like ip-10-0-1-5.ec2.internal (in us-east-1) or ip-10-0-1-5.eu-west-1.compute.internal. Private hosted zones cannot use .internal — that namespace is AWS-managed.

Default resolver and EC2

EC2 instances by default have /etc/resolv.conf pointing at the VPC+2 resolver. To change this, you must override it via DHCP option set (next section) or manually edit /etc/resolv.conf on each instance.

Inbound Endpoint — On-Prem→AWS Resolution

An inbound endpoint is a cluster of ENIs (one per AZ) that receive DNS queries from on-premises systems and resolve them using the VPC's resolver rules and PHZ associations. It is the bridge from on-prem DNS to AWS-side DNS resolution.

When you need an inbound endpoint

• On-premises systems need to resolve a private hosted zone associated with a VPC (e.g., db.aws.example.com pointing to an RDS endpoint).
• On-premises systems need to resolve interface endpoint private DNS names (e.g., secretsmanager.us-east-1.amazonaws.com via PrivateLink).
• On-premises systems need to resolve any AWS-internal name accessible only from within a VPC.

Configuration

1. Create an inbound endpoint in a VPC, selecting one subnet per AZ (typically two AZs minimum).
2. AWS provisions one ENI per selected subnet with a private IP from the subnet CIDR.
3. Associate a security group allowing inbound TCP 53 + UDP 53 from on-premises CIDRs.
4. Configure on-premises DNS servers to conditionally forward queries for AWS-side domains to the inbound endpoint IPs.

Worked example — on-prem resolving aws.example.com

• AWS-side PHZ aws.example.com is associated with VPC. Records: db.aws.example.com → 10.0.5.42.
• Inbound endpoint deployed with ENIs at 10.0.1.10 and 10.0.2.10 (two AZs).
• On-premises DNS server (e.g., BIND) is configured: forward zone "aws.example.com" { forwarders { 10.0.1.10; 10.0.2.10; }; };.
• On-prem client queries db.aws.example.com. On-prem DNS forwards to inbound endpoint. Inbound endpoint resolves via PHZ. Returns 10.0.5.42 to on-prem client.

Inbound endpoint and Direct Connect / VPN

The on-prem to inbound endpoint traffic must reach the VPC over Direct Connect or Site-to-Site VPN. The inbound endpoint ENIs have private IPs in the VPC's CIDR, reachable via the hybrid connection. This is why you cannot use inbound endpoints from arbitrary on-premises locations without connectivity.

Cost

Inbound endpoints have per-AZ per-hour charges and per-million queries charges. Cost is modest for moderate query volumes; scales linearly with query rate.

Outbound Endpoint — AWS→On-Prem Resolution

An outbound endpoint is a cluster of ENIs (one per AZ) that forward DNS queries from the AWS resolver out to specified target IPs — typically on-premises DNS servers. It enables the resolver to recursively answer queries for on-premises domains.

When you need an outbound endpoint

• AWS instances or Lambdas need to resolve on-premises Active Directory names (e.g., dc1.corp.example.com).
• AWS instances need to resolve internal corporate domains hosted only on-prem.
• AWS workloads must use on-prem DNS for everything (split-horizon, zone-specific forwarding).

Configuration

1. Create an outbound endpoint in a VPC, selecting subnets per AZ.
2. AWS provisions ENIs in the selected subnets.
3. Create one or more forward rules specifying domain → target IPs (e.g., corp.example.com → 10.1.0.5, 10.1.0.6).
4. Associate the rules with VPCs that should apply them.
5. Ensure the outbound endpoint has connectivity to the on-prem DNS server IPs (via DX/VPN, route tables).
6. Configure the security group on the outbound endpoint ENIs to allow outbound to on-prem DNS server IPs.

Forward rules — the routing primitive

A forward rule specifies:

• Rule name and rule ID.
• Domain name to match (e.g., corp.example.com). Suffix matching: corp.example.com matches dc1.corp.example.com and any subdomain.
• Target IPs — list of resolver IPs to forward to (typically on-prem DNS servers).
• Associated VPCs — VPCs in which this rule is applied.

Multiple forward rules can be associated with the same VPC. Most-specific match wins (longest domain suffix), similar to BGP longest prefix match.

Worked example — AWS resolving corp.example.com

• VPC contains EC2 instance and Lambda function.
• On-prem AD has DCs at 10.1.0.5 and 10.1.0.6 hosting corp.example.com.
• Outbound endpoint deployed in VPC with ENIs at 10.0.5.10 and 10.0.6.10.
• Forward rule: corp.example.com → 10.1.0.5, 10.1.0.6 associated with VPC.
• EC2 queries dc1.corp.example.com. VPC+2 resolver consults rules. Forward rule matches. Resolver sends query via outbound endpoint to 10.1.0.5 (or 10.1.0.6 with failover). Response returned to EC2.

Direct connect requirement

Outbound endpoint queries to on-prem DNS server IPs traverse the hybrid connection (DX or VPN). The route table for the outbound endpoint subnet must reach the on-prem DNS server CIDR. Security group on outbound endpoint must allow outbound TCP 53 + UDP 53 to the on-prem CIDR.

Resolver Rules — Forward, System, and Autodefined

A resolver rule is a configuration that determines how queries for specific domains are handled. Three types exist.

Forward rules — manually authored

Forward rules forward queries for a specific domain to specified target IPs (typically on-prem). Created and managed by the customer. Associated with one or more VPCs.

System rules — AWS-managed defaults

System rules are AWS-managed and cannot be modified. They handle:

• Public DNS recursive resolution for unknown domains.
• .internal zone resolution for AWS-managed internal names.
• Default behaviour when no other rule matches.

Autodefined rules — internal AWS

Autodefined rules are auto-created for AWS-internal services (like AWS PHZ for .amazonaws.com). Customers do not manage these directly.

Rule evaluation priority

When a query arrives at the resolver, rules are evaluated in this order:

1. Most-specific forward rule match wins.
2. If no forward rule matches, autodefined rules apply.
3. If neither matches, the system rule for public DNS recursive resolution handles it.

Worked example — overlapping rules

VPC has two forward rules:

• Rule A: example.com → 10.1.0.5 (broad)
• Rule B: prod.example.com → 10.2.0.5 (specific)

Query for db.prod.example.com matches Rule B (longest suffix). Query for web.example.com matches Rule A. Most-specific wins.

DHCP Option Sets — Customising VPC DNS Configuration

A DHCP option set is a VPC-level configuration that specifies what DHCP options new instances receive when launched. The most-relevant options for DNS are domain-name-servers and domain-name.

Default DHCP option set

By default, VPCs use a DHCP option set with:

• domain-name-servers: AmazonProvidedDNS (i.e., the VPC+2 resolver).
• domain-name: <region>.compute.internal (or ec2.internal in us-east-1).

This means new EC2 instances get the VPC+2 resolver as their DNS server and the AWS-internal domain as their search domain.

Custom DHCP option set use cases

• Force on-prem DNS as primary: set domain-name-servers to the on-prem DNS IPs. New instances will use on-prem DNS for all queries.
• Use Route 53 Resolver inbound endpoint as primary: set domain-name-servers to the inbound endpoint IPs. Useful if the resolver itself sits in a different VPC.
• Custom search domain: set domain-name to corp.example.com so unqualified queries resolve as <host>.corp.example.com.

Switching DHCP option sets

A VPC has exactly one DHCP option set at a time. Switching requires creating a new option set and associating it. Existing instances do not auto-update — they retain their current DHCP lease until renewed (typically hours or days), or until rebooted.

Forcing on-prem DNS — the AD-joined VPC pattern

A common ANS-C01 scenario: AWS instances must use on-prem AD DCs as their primary DNS to support AD-joined Windows / Linux SSSD. Configure DHCP option set with domain-name-servers set to AD DC IPs (e.g., 10.1.0.5, 10.1.0.6, AmazonProvidedDNS as fallback). Note: this changes resolution behaviour for ALL queries from instances, not just AD names. To avoid breaking AWS service resolution, you can include AmazonProvidedDNS in the list as a fallback.

Sharing Resolver Rules Across Accounts via AWS RAM

In multi-account organisations, the central network team typically manages resolver rules and shares them to workload accounts. AWS Resource Access Manager (RAM) is the sharing mechanism.

Sharing model

1. Central network account creates the outbound endpoint and forward rules.
2. Network account creates a RAM resource share including the resolver rule.
3. Network account adds member accounts (or the entire AWS Org) as principals.
4. Member accounts receive the share and can associate the rule with their own VPCs.

Why share rules instead of replicating

Without sharing: each account creates its own outbound endpoint and rules. Duplicate effort, duplicate cost (per-AZ per-hour outbound endpoint charges multiplied), drift risk.

With sharing: one outbound endpoint in the network account, one set of rules, applied to many VPCs across many accounts. Operationally simple and cost-efficient.

Region restriction

Resolver rules are regional — a rule in us-east-1 cannot be shared to VPCs in us-west-2. For multi-region orgs, each region has its own outbound endpoint and rule set, shared regionally.

Cross-region resolver rules — not supported directly

You cannot directly share a resolver rule across regions. For multi-region hybrid DNS, deploy outbound endpoints in each region with parallel rules.

Centralised DNS Architecture — The Multi-Account Pattern

The canonical ANS-C01 multi-account hybrid DNS pattern:

Central network account contains

• Inbound endpoint in a "DNS-hub" VPC, for on-prem to query AWS-side names.
• Outbound endpoint in the same DNS-hub VPC, for AWS to query on-prem names.
• Forward rules: corp.example.com → on-prem DC IPs (for AD names), plus any other on-prem domains.
• Private Hosted Zones for AWS-side names like aws.example.com, associated with all relevant VPCs across accounts via cross-account PHZ association.

RAM sharing

• Resolver rules shared via RAM to all member accounts.
• PHZs associated with member account VPCs via the cross-account PHZ association API.

Member accounts

• Workload VPCs use VPC+2 resolver (AmazonProvidedDNS) — no DHCP option set changes.
• VPC+2 resolver applies the shared resolver rules to forward corp.example.com queries to on-prem (via the central outbound endpoint).
• VPC+2 resolver answers aws.example.com queries from the associated PHZ.
• Public DNS queries flow normally via system rule.

On-premises

• On-prem DNS server has a conditional forwarder for aws.example.com → inbound endpoint IPs.
• On-prem queries db.aws.example.com → forwards to inbound endpoint → resolver answers from PHZ → returns to on-prem.

Route 53 Resolver DNS Firewall — Domain Filtering for Outbound DNS

Route 53 Resolver DNS Firewall filters outbound DNS queries from VPC instances based on domain allow-lists or deny-lists. It is the AWS-managed answer to "block C2 callbacks via DNS exfiltration".

Architecture

A rule group contains one or more rules. Each rule has:

• Domain list — a managed list of FQDNs (allow, block, alert).
• Action — ALLOW, BLOCK, ALERT, or NXDOMAIN response.
• Priority — order of evaluation.

Rule groups are associated with VPCs. Queries from VPC instances pass through the firewall before reaching the default resolver.

Use cases

• Block known malicious domains — managed domain lists from AWS or third parties (Spamhaus, OpenPhish equivalents).
• Restrict outbound DNS to corporate-approved domains (allow-list-only mode).
• Detect DNS exfiltration — alert on queries to suspicious TLDs or recently registered domains.

Integration with Firewall Manager

Route 53 Resolver DNS Firewall policies can be deployed org-wide via AWS Firewall Manager, ensuring every VPC has the same baseline DNS security policy.

Cost

Per-million queries, plus per-rule-group-association hourly. Modest for typical workloads; scales with DNS query rate.

Hybrid DNS Pattern — Active Directory Joined VPCs

The most-tested specific scenario on ANS-C01: AWS workloads need to be AD-joined to an on-premises Active Directory.

Requirements

• AWS instances must resolve corp.example.com and AD-internal names like dc1.corp.example.com, _ldap._tcp.corp.example.com (SRV records).
• AWS instances must reach AD DCs at on-prem IPs over Direct Connect or VPN.
• AWS instances may need to register their hostnames in AD DNS (dynamic DNS update).

Solution

Option 1: Outbound endpoint + forward rule (recommended for most cases).

• Outbound endpoint in network account VPC.
• Forward rule corp.example.com → on-prem DC IPs.
• Shared via RAM to workload accounts; rules associated with workload VPCs.
• AWS instances use VPC+2 resolver, which forwards corp.example.com queries via outbound endpoint to on-prem DCs.

Option 2: DHCP option set pointing at on-prem DCs (legacy, still valid).

• Set DHCP option set domain-name-servers to on-prem DC IPs.
• Instances use on-prem DCs for all DNS, including corp.example.com and public DNS.
• Side effect: AWS service DNS (s3.amazonaws.com, etc.) is also resolved via on-prem — adds latency.

Option 3: AWS Managed Microsoft AD with trust (newer, AWS-native).

• Deploy AWS Managed Microsoft AD in the VPC.
• Establish trust with on-prem AD.
• AWS instances join the AWS Managed AD; resolver uses Managed AD DNS.

For ANS-C01, Option 1 (outbound endpoint with forward rule) is the canonical answer. Option 2 is legacy. Option 3 is more SAP-C02 / SAA territory.

Common Traps Recap — Route 53 Resolver on ANS-C01

Trap 1: Inbound and outbound names refer to the on-prem direction

Wrong. Inbound and outbound are named from the AWS resolver's perspective. Inbound = traffic into AWS resolver; outbound = traffic out of AWS resolver.

Trap 2: One resolver endpoint serves all regions

Wrong. Resolver endpoints and rules are regional. Multi-region needs per-region deployments.

Trap 3: DHCP option set updates apply immediately

Wrong. Existing instances retain old DHCP lease until renewal or reboot.

Trap 4: PHZ can host .internal zones

Wrong. .internal is AWS-reserved. Use a custom domain (e.g., aws.example.com).

Trap 5: Resolver rules are global

Wrong. Resolver rules are per-region. To share, use RAM within the same region only.

Trap 6: Outbound endpoint resolves AWS PHZ for on-prem

Wrong. Outbound endpoint forwards from AWS resolver to on-prem. To let on-prem resolve AWS PHZ, use inbound endpoint + on-prem conditional forwarder.

Trap 7: VPC+2 resolver is the same IP for every VPC

Wrong. VPC+2 is a calculation — base CIDR + 2. For 10.0.0.0/16, it is 10.0.0.2. For 172.31.0.0/16, it is 172.31.0.2.

Trap 8: Resolver DNS Firewall blocks all DNS over UDP/TCP

Wrong. Resolver DNS Firewall filters based on domain names, not protocol. To block DNS over HTTPS or DNS over TLS, use Network Firewall or third-party.

FAQ — Route 53 Resolver and Hybrid DNS

Q1: When do I need an inbound endpoint versus an outbound endpoint?

Inbound endpoint for resolving AWS-side names from on-premises. Example: on-prem servers need to resolve db.aws.example.com (a record in a private hosted zone associated with a VPC). On-prem DNS conditional-forwards to the inbound endpoint, which resolves via the PHZ. Outbound endpoint for resolving on-premises names from AWS. Example: AWS Lambdas need to resolve dc1.corp.example.com (an Active Directory DC). VPC+2 resolver forwards via outbound endpoint to on-prem DNS. Many hybrid deployments need both — an inbound endpoint for on-prem-to-AWS and an outbound endpoint for AWS-to-on-prem. The names are confusing because they are from the resolver's perspective: inbound = traffic flows into the resolver; outbound = traffic flows out from the resolver.

Q2: How do I share a resolver rule across many accounts and VPCs?

Create the resolver rule in a central network account. Use AWS Resource Access Manager (RAM) to create a resource share including the resolver rule. Add member accounts (or the entire AWS Organisation) as principals. Member accounts can then accept the share and associate the rule with their own VPCs via the Route 53 Resolver console or API. The rule is defined once in the central account but applied to many VPCs. The outbound endpoint backing the rule is in the central account and shared use is implicit through the rule. Note: rules are regional — share only within the same region. For multi-region, repeat the pattern in each region.

Q3: What is the difference between conditional forwarding and split-horizon DNS?

Conditional forwarding is a configuration on a DNS server (or Route 53 Resolver via forward rules) that says "for queries about specific domain X, forward to specific target Y". It is name-pattern-based routing of queries. Split-horizon DNS is the practice of having different DNS answers for the same query depending on where the query came from. Example: api.example.com resolves to a public IP from public internet but to a private IP from VPC. Split-horizon is a deployment pattern, achieved on AWS via private hosted zones (which override public DNS for VPCs they are associated with). Conditional forwarding is the mechanism; split-horizon is the result. ANS-C01 questions use both terms — recognise that they are related but not synonyms.

Q4: How does the VPC+2 resolver compare to using my own DNS servers?

VPC+2 (AmazonProvidedDNS) is AWS-managed, automatically scaling, free, and handles PHZ associations, public DNS, .internal, and resolver rules out of the box. Trade-offs: you cannot customise its behaviour beyond what Route 53 Resolver supports. Custom DNS servers (BIND on EC2, Windows DNS, etc.) give full control: arbitrary zones, custom views, integration with AD, advanced filtering. Trade-offs: you manage availability, scaling, security, and patching. Most AWS workloads use VPC+2 with optional resolver rules and DNS Firewall — this covers the majority of needs. Custom DNS is useful for AD-integrated workloads (sometimes), legacy applications with hardcoded DNS expectations, or when AWS-managed features are insufficient. For ANS-C01, default to VPC+2 + resolver rules unless the question explicitly requires custom DNS.

Q5: How do I configure a VPC so that EC2 instances use on-premises DNS as their primary?

Two patterns. Pattern 1 (recommended): outbound endpoint + forward rule. Keep VPC+2 as the primary resolver (default). Add forward rules for the on-prem domains to forward via outbound endpoint. AWS service DNS still resolves via VPC+2 (fast); on-prem domains forward to on-prem (correct). Pattern 2 (legacy): DHCP option set. Create a custom DHCP option set with domain-name-servers = <on-prem DC IPs>, AmazonProvidedDNS. Associate with VPC. New instances will use on-prem DCs first, falling back to AmazonProvidedDNS. Side effect: all DNS, including AWS service DNS, goes through on-prem first — adds latency and load on on-prem DCs. Pattern 1 is the modern best practice; Pattern 2 is necessary only for legacy AD-joined Windows where DHCP option set is the standard expectation.

Q6: What happens when I associate a private hosted zone with a VPC?

The PHZ becomes the authoritative answer for that domain within the VPC. Queries from VPC instances for the PHZ's domain (e.g., db.aws.example.com) return PHZ records, bypassing public DNS. PHZ records are visible only from associated VPCs — public internet sees nothing or different records. Cross-account PHZ association: a PHZ in account A can be associated with a VPC in account B via the create-vpc-association-authorization (account A) + associate-vpc-with-hosted-zone (account B) API calls. This is the canonical multi-account hybrid DNS pattern: PHZs in the central account, associated with workload VPCs across many accounts. PHZs do not propagate via VPC peering or TGW — explicit cross-account association is required.

Q7: How do I let on-premises systems resolve a private hosted zone associated with multiple VPCs?

Step 1: deploy an inbound endpoint in any one VPC that has the PHZ associated with it (the inbound endpoint accesses the resolver, which sees the PHZ). Step 2: configure on-premises DNS server with a conditional forwarder for the PHZ's domain pointing at the inbound endpoint IPs (typically two ENIs across two AZs for HA). Step 3: from on-prem, query the PHZ's records — the on-prem DNS forwards to the inbound endpoint, which resolves from the PHZ and returns the answer. Note: on-prem must have IP connectivity to the inbound endpoint ENIs (via Direct Connect or VPN), and the security group on the inbound endpoint must allow inbound TCP/UDP 53 from on-prem CIDRs. The same inbound endpoint can serve many on-prem clients and many PHZs (any PHZ associated with the endpoint's VPC is reachable).

Q8: What is the difference between Route 53 Resolver DNS Firewall and AWS Network Firewall for DNS filtering?

Route 53 Resolver DNS Firewall filters at the DNS query layer based on the queried domain name. It can ALLOW, BLOCK, ALERT, or return NXDOMAIN. It is purpose-built for DNS — efficient, AWS-managed, with managed domain lists. AWS Network Firewall filters at the packet layer with Suricata-compatible stateful rules. It can inspect DNS protocol packets, but is more general-purpose. For pure DNS filtering (block known-bad domains, restrict to allow-listed domains), use Resolver DNS Firewall — it is cheaper, simpler, and DNS-aware. For deep packet inspection of all protocols including DNS-over-HTTPS and DNS-over-TLS (which Resolver DNS Firewall does not handle), use Network Firewall with appropriate rules. Many deployments use both: Resolver DNS Firewall for default DNS filtering, Network Firewall for protocol-level inspection of suspicious flows.

Q9: How do I architect resolver rules to support a mix of corporate AD domains and AWS-internal subdomains in the same namespace?

Suppose corporate uses example.com with AD at corp.example.com, and AWS workloads use aws.example.com for AWS resources. Architecture: PHZ for aws.example.com in the network account, associated with all relevant workload VPCs. Records for AWS resources (db.aws.example.com → 10.0.5.42). Forward rule for corp.example.com → on-prem DC IPs in the network account, shared via RAM, associated with workload VPCs. Public DNS for example.com itself (the parent zone) handles the rest. Resolver evaluation: query for db.aws.example.com → PHZ wins (most-specific). Query for dc1.corp.example.com → forward rule wins. Query for www.example.com (parent zone) → falls through to public DNS via system rule. The result: each subdomain is resolved by the right authority without conflict.

Q10: How do I ensure DNS HA across AZs for hybrid resolution?

For inbound and outbound endpoints, deploy ENIs in at least two AZs (typically the same AZs as the workload). Each endpoint provisions one ENI per selected subnet; queries are load-balanced across ENIs by the on-prem DNS or AWS resolver. If one AZ fails, the other ENI continues serving. For on-prem conditional forwarding to AWS inbound endpoint, configure the on-prem DNS with both inbound endpoint IPs as forwarders (typically two for two AZs); on-prem DNS will failover between them. For outbound endpoint forwarding to on-prem, the forward rule's target IPs should include multiple on-prem DC IPs for failover. The Route 53 Resolver itself (VPC+2) is regional and AZ-redundant — no AZ-specific availability concern. End-to-end HA: VPC+2 (regional) → outbound endpoint (multi-AZ ENI) → on-prem DC IPs (multi-DC). Each layer has redundancy and the system survives any single AZ or DC failure.

Further Reading

• Resolving DNS Queries Between VPCs and Your Network
• Route 53 Resolver Getting Started
• Managing Resolver Rules
• Route 53 Resolver DNS Firewall
• DHCP Option Sets
• Working with Private Hosted Zones
• AWS ANS-C01 Exam Guide

Route 53 Resolver is the hybrid DNS plane; the next layers on ANS-C01 are Route 53 public, private, and traffic policies for the broader DNS feature set; VPC architecture and subnetting because resolver IP placement depends on subnet design; Transit Gateway routing for the underlying network connecting hybrid DNS endpoints; and IaC patterns for declaring resolver rules and endpoint shares declaratively.

• Route 53 DNS — Public, Private, and Hybrid Architectures
• VPC Architecture, CIDR Design, and Subnetting
• Transit Gateway — Routing Tables, Attachments, and Connect
• IaC for Network Infrastructure — CloudFormation, CDK, and Terraform