Hybrid DNS with Route 53 Resolver and On-Premises Integration

What Is a Hybrid DNS Resolver on AWS?

A hybrid DNS resolver is the name resolution layer that lets a DNS query originating inside a VPC reach private zones hosted on-premises, and conversely lets a DNS query originating on-premises reach private zones hosted inside AWS. On AWS, the hybrid DNS resolver is implemented by Amazon Route 53 Resolver — a managed, regional DNS service that runs by default inside every VPC and can be extended with Resolver endpoints and Resolver Rules to bridge DNS traffic between the cloud and a corporate datacenter, a remote office, or a partner network connected via AWS Site-to-Site VPN, AWS Direct Connect, or AWS Transit Gateway.

For the AWS SAP-C02 exam, hybrid DNS resolver design is a recurring theme in Domain 1 (Design Solutions for Organizational Complexity) and Domain 2 (Design for New Solutions). Expect scenarios like "on-premises Active Directory users must resolve AWS private endpoints," "a shared service VPC hosts central DNS for dozens of spoke VPCs," "multiple AWS accounts need the same conditional forwarding rules without redundant configuration," and "DNS queries must be logged to CloudWatch for compliance." The right answer almost always combines a hybrid DNS resolver built on Route 53 Resolver inbound endpoints, outbound endpoints, Resolver Rules shared via AWS Resource Access Manager (RAM), Route 53 Private Hosted Zones (PHZ) associated across VPCs and accounts, and sometimes DNSSEC signing or Resolver Query Logging for governance.

This topic goes deeper than the CLF-C02 Route 53 overview. The hybrid DNS resolver is not just "Route 53 with extra steps" — it is an architectural control plane that determines whether your multi-account landing zone can actually resolve names reliably, whether a compromised resolver can be audited, and whether a legacy Active Directory forest can coexist with cloud-native service discovery. A professional solutions architect must know exactly when to deploy a hybrid DNS resolver with inbound endpoints, when outbound endpoints are required, how forwarding rules are scoped, and how Transit Gateway changes the DNS topology. Every byte of this guide is calibrated for SAP-C02 scenario questions.

Analogy 1 — The International Phone Switchboard (Inbound vs Outbound Endpoints)

Think of your VPC as a skyscraper full of tenants who each have an internal phone extension (private IP). The Route 53 Resolver is the building's central switchboard operator — she answers every internal call ("Who is payments.internal?") and routes it to the right extension. But the skyscraper also has two dedicated phone jacks on the loading dock for wires that run out of the building.

The inbound endpoint is the jack where calls come into the building from the outside world — specifically from your on-premises datacenter. An on-prem DNS server dials the inbound endpoint's IP as if it were any external DNS server, and the Resolver inside the building answers for AWS private names such as *.awscloud.internal or a Private Hosted Zone. The outbound endpoint is the jack where calls leave the building — when a VPC instance asks for corp.example.com, the Resolver hands the call out through the outbound endpoint to the on-prem DNS server. The direction of traffic is defined from the VPC's perspective: inbound = traffic into the VPC resolver; outbound = traffic out of the VPC resolver. This direction is the single most-tested trap in SAP-C02 hybrid DNS resolver questions.

Analogy 2 — The Shared Phonebook on AWS RAM (Resolver Rules)

Imagine each AWS account is a different family living in apartments, each with its own phonebook (VPC's local resolver state). Resolver Rules are entries in a master phonebook kept by the Network account: "If anyone asks for corp.example.com, look it up at phone number 10.1.2.3 (the on-prem DNS server)." The problem is that if every family bought their own copy of the master phonebook, you would have 50 copies to update whenever a corporate DNS server moves. Instead, the Network account publishes the master phonebook via AWS Resource Access Manager (RAM), and every family simply subscribes to a single shared copy. When the master is updated, all 50 families see the change instantly. This is exactly how a hybrid DNS resolver scales in AWS Control Tower / Landing Zone architectures.

Analogy 3 — The Pneumatic Tube System (Transit Gateway DNS over Peering)

In old department stores, cashiers used pneumatic tubes to shoot paperwork between floors. AWS Transit Gateway is that pneumatic tube system for packets — including DNS packets. When a spoke VPC asks its local resolver for legacy.corp.example.com, the query travels out of the spoke VPC through the outbound endpoint, into the Transit Gateway, across to the on-prem side via Direct Connect or VPN, and back again with the answer. But here is the catch: Transit Gateway does not carry DNS state; it only carries the raw UDP/TCP DNS packets. DNS must be designed end-to-end at the Resolver layer. Tubes move paper; they do not read it.

With the switchboard, the shared phonebook, and the pneumatic tube in your head, the rest of this hybrid DNS resolver guide becomes a matter of matching each mechanism to its exam scenario.

Route 53 Resolver — The Default VPC Resolver

Every VPC in every AWS Region ships with a Route 53 Resolver running at the reserved IP VPC_CIDR + 2 (for example, 10.0.0.2 for a 10.0.0.0/16 VPC) and also at the universal IP 169.254.169.253. This in-VPC resolver is the starting point of any hybrid DNS resolver design. It answers three kinds of queries:

1. Public DNS — amazon.com, google.com, anything on the public internet. The Resolver recursively queries the DNS root and authoritative servers.
2. AWS-owned private DNS — EC2 instance hostnames (ip-10-0-1-23.ec2.internal), VPC endpoint DNS names, ALB/NLB DNS, and AWS service endpoints.
3. Customer-private DNS — Private Hosted Zones (PHZ) associated with the VPC, and any Resolver Rules pointing to on-prem or third-party resolvers.

The in-VPC Resolver is implicit: you cannot turn it off, you cannot list it in the console, and it is regional-scoped. You can only see it in action by running dig from an EC2 instance and observing that queries are answered from AmazonProvidedDNS. When the default Resolver is insufficient — because on-prem servers need to reach into AWS, or AWS workloads need to reach out to on-prem — you add Resolver endpoints.

Resolver Inbound Endpoints — On-Prem to AWS

A Resolver inbound endpoint is a set of Elastic Network Interfaces (ENIs) placed in subnets inside your VPC, each assigned a private IP from the subnet's CIDR. On-premises DNS servers are configured to forward queries for AWS private names (for example, *.awscloud.internal or a PHZ domain like internal.examhub.cc) to the inbound endpoint IPs. From the on-prem server's perspective, the inbound endpoint IPs look like any other DNS server; from the AWS side, those ENIs deliver the query to the in-VPC Resolver, which then looks the name up against associated PHZs.

Why Use an Inbound Endpoint?

• On-prem users need to resolve AWS private endpoints such as vpce-123.execute-api.us-east-1.vpce.amazonaws.com — the classic SAP-C02 hybrid DNS resolver scenario.
• Corporate workstations must reach internal services running behind ALBs in a VPC without using the public internet.
• CI/CD pipelines in the datacenter must resolve private RDS endpoints in a VPC over Direct Connect.

Requirements

• At least two ENIs in two different AZs for high availability. AWS recommends a minimum of two IP addresses per endpoint; the console will force the choice.
• A Security Group allowing inbound UDP/TCP port 53 from the on-prem CIDR ranges.
• A route back from the VPC to on-prem over VPN, Direct Connect, or Transit Gateway — DNS is a request-response protocol, so return traffic must reach the on-prem resolver.
• An associated Private Hosted Zone (or default ec2.internal behavior) for the names you want to expose.

Cost Model

Resolver inbound endpoints bill per-ENI per-hour plus a per-query charge. At the time of writing, each ENI costs roughly $0.125/hour ($90/month), and you need two for HA — so budget about $180/month per inbound endpoint. Multiply by regions.

Resolver Outbound Endpoints — AWS to On-Prem

A Resolver outbound endpoint is the mirror image. It is again a set of ENIs in VPC subnets, but this time the ENIs are the egress point for DNS queries leaving the VPC toward an on-prem DNS server. Outbound endpoints are paired with Resolver Rules that say "for these domain names, forward the query to these target IPs."

Why Use an Outbound Endpoint?

• VPC workloads need to resolve on-prem private names like payroll.corp.example.com or ldap.ad.example.com.
• Lift-and-shift migrations where the EC2 instance still calls a legacy hostname pointing at an on-prem database.
• Hybrid Active Directory where domain-joined EC2 instances must locate on-prem AD controllers via SRV records.

How Queries Flow

1. An EC2 instance in the VPC queries ldap.ad.example.com.
2. The in-VPC Resolver at VPC_CIDR + 2 checks associated PHZs and auto-defined rules — no match.
3. The Resolver checks Resolver Rules: a forwarding rule says ad.example.com → 10.1.1.53, 10.1.1.54 via outbound endpoint rslvr-out-abc.
4. The query is sent out the outbound endpoint ENI, over the VPC route table, into the VGW/TGW, across the VPN or Direct Connect, to the on-prem DNS server at 10.1.1.53.
5. The answer returns via the same path.

Requirements

• Minimum two ENIs in two AZs.
• Security Group allowing outbound UDP/TCP port 53 to the on-prem DNS server IPs.
• Forwarding route from the VPC to the on-prem DNS server's IP via VPN/DX/TGW.
• At least one Forwarding Rule associated with the VPC.

Resolver Rules — Forwarding, System, and Auto-Defined

A Resolver Rule is a DSL statement that tells the VPC Resolver what to do with queries for a specific domain name. There are three kinds that SAP-C02 tests.

1. Forwarding Rules (Custom)

The most common kind: "For domain X, forward queries to IPs [Y, Z] via outbound endpoint E." You create these explicitly. A forwarding rule has:

• Domain name — the suffix to match, e.g., corp.example.com. Matching is longest-suffix-wins, so ad.corp.example.com beats corp.example.com.
• Target IPs — up to six DNS server IPs on-prem or in another VPC.
• Outbound endpoint — the VPC egress path.
• Associations — a list of VPCs that use this rule. One rule can be associated with many VPCs.

2. System Rules

System Rules are built-in rules that Route 53 Resolver always applies. The most important system rule says: "For AWS-reserved domains (like amazonaws.com, compute.internal, ec2.internal), always resolve internally — never forward to a custom rule." This is what prevents you from accidentally breaking EC2 metadata or VPC endpoint DNS by creating a wildcard forwarding rule. You cannot delete or modify system rules, but you can override narrower sub-domains (for example, forwarding legacy.amazonaws.com if you really, really insisted — which you should not).

3. Auto-Defined Rules

When you associate a Private Hosted Zone (PHZ) with a VPC, Route 53 silently installs an auto-defined rule that routes queries for that PHZ's domain to the internal PHZ lookup. You do not see these rules in the Resolver Rules list, but they exist. Auto-defined rules always lose to a longer-suffix explicit rule, but they beat rules of equal specificity — so a PHZ for internal.examhub.cc will trump a forwarding rule for the same exact suffix.

Rule Evaluation Order

Given a query for payroll.corp.example.com, the Resolver evaluates in this order:

1. Longest-suffix-match first — wins regardless of rule kind.
2. System rule with equal suffix — beats auto-defined.
3. Auto-defined (PHZ) with equal suffix — beats custom forwarding.
4. Custom forwarding rule with equal suffix — final fallback.

In 95% of real designs you never hit a tie; the longest suffix wins and you are done.

Sharing Resolver Rules via AWS RAM Across Accounts

In a multi-account landing zone — AWS Control Tower, AWS Organizations, or a hand-rolled hub-and-spoke — you do not want every account to define its own copy of the forwarding rules. The operational cost of keeping them in sync is unacceptable, and drift creates silent resolution failures. The correct pattern is to centralize Resolver Rules in a Network account and share them via AWS Resource Access Manager (RAM).

How the Sharing Works

1. The Network account creates the outbound endpoint and the forwarding rules that target on-prem DNS servers.
2. The Network account opens AWS RAM and creates a Resource Share that includes the Resolver Rules.
3. The Resource Share grants access to principals: individual AWS account IDs, an Organizational Unit (OU), or the entire AWS Organization.
4. Each consumer account accepts the share (or auto-accepts if within the Organization and the share is set to trust the Organization).
5. In each consumer account, the administrator associates the shared rule with one or more of their VPCs. The association is still owned by the consumer account, so they control which of their VPCs use the rule.

The outbound endpoint itself stays in the Network account — you do not share endpoints. Only rules are shareable. Traffic from consumer VPCs reaches the centralized endpoint via Transit Gateway or VPC peering; the endpoint is reachable because its ENIs live in the Network VPC, which is attached to the TGW.

What This Saves

• One outbound endpoint to pay for instead of N (saves roughly $90/month per avoided endpoint, times two for HA).
• One set of forwarding rules to edit when on-prem DNS IPs change.
• Consistent resolution behavior across the organization — no spoke drifts.

What It Does Not Share

• Private Hosted Zones are not shared via RAM; PHZs are "associated" with VPCs across accounts using a different, explicit cross-account association mechanism (covered below).
• Inbound endpoints are also not shared — but typically you do not need to. One inbound endpoint in the Network VPC, reachable via TGW, handles all on-prem queries.

Route 53 Private Hosted Zones (PHZ)

A Private Hosted Zone is a DNS zone that is only resolvable from specifically associated VPCs. PHZs are the AWS-native way to publish internal domain names like internal.examhub.cc, vpce.examhub.cc, or svc.payments.examhub.cc. A PHZ holds the usual RR types — A, AAAA, CNAME, TXT, SRV, MX — plus Alias records that target AWS resources (ELB, CloudFront, S3 website, another PHZ record in the same zone).

Key Properties

• A PHZ is visible only from associated VPCs. Queries from the public internet for the zone's domain will fail (or fall back to a public zone of the same name if one exists — the split-horizon pattern, see below).
• A VPC can be associated with multiple PHZs (e.g., internal.examhub.cc and legacy.examhub.com on the same VPC).
• A PHZ can be associated with multiple VPCs across the same AWS account, or cross-account via a two-step authorization handshake.
• VPC enableDnsHostnames and enableDnsSupport must both be true for PHZ resolution to work — a classic silent failure mode.

Cross-VPC Association (Same Account)

Easy: in the Route 53 console, edit the PHZ and add another VPC ID. Both VPCs now resolve the zone.

Cross-Account PHZ Association (Two-Step)

A PHZ in account A can be associated with a VPC in account B, but there is a two-step dance:

1. Account A runs create-vpc-association-authorization --hosted-zone-id Z123 --vpc VPCRegion=...,VPCId=vpc-abc to authorize account B's VPC.
2. Account B runs associate-vpc-with-hosted-zone --hosted-zone-id Z123 --vpc VPCRegion=...,VPCId=vpc-abc to complete the association.
3. Account A (optionally) runs delete-vpc-association-authorization to revoke the standing authorization, since the association itself persists.

Afterward, the VPC in account B can resolve the PHZ. This cross-account association is the standard pattern for a shared service VPC that hosts central DNS — the central VPC owns the PHZ, and spoke VPCs in other accounts are associated in.

PHZ Cannot Be Shared via RAM

A common trap: PHZs are not shareable via AWS RAM. You must use the two-step VPC association API above. Do not confuse this with Resolver Rules, which are shareable via RAM.

Split-Horizon DNS Patterns

Split-horizon DNS (a.k.a. split-brain or split-view DNS) means the same domain resolves differently depending on who is asking. It is a foundational hybrid DNS resolver pattern. The canonical example: api.examhub.cc should resolve to a public CloudFront distribution for external customers, and to an internal ALB private IP for VPC workloads and on-prem users.

Implementation on AWS

1. Create a public hosted zone for examhub.cc containing api.examhub.cc → cloudfront-xxx.cloudfront.net (alias).
2. Create a Private Hosted Zone for examhub.cc containing api.examhub.cc → internal-alb-yyy.elb.amazonaws.com (alias).
3. Associate the PHZ with every VPC that should see the private view.
4. For on-prem users who also need the private view, configure an inbound endpoint in the VPC where the PHZ is associated, and add a forwarding rule on the on-prem DNS server: examhub.cc → inbound-endpoint-IPs.

The VPC Resolver's Priority Rule

When a VPC is associated with a PHZ for examhub.cc, queries from inside that VPC for any name ending in examhub.cc go to the PHZ first. If the PHZ has a record, you get the private answer. If the PHZ has no record for the specific name, the Resolver does not fall back to the public zone by default — you either get NXDOMAIN or, depending on the wildcard setup in the PHZ, a catchall answer.

This "no fallback" behavior is a common surprise. If you want the public answer for names missing from the PHZ, you must either mirror those records into the PHZ or disable the PHZ for specific queries.

Why Split-Horizon Matters for SAP-C02

Split-horizon is the default design for any enterprise that publishes an API both publicly and privately, or a web app that is internet-facing but has an admin portal visible only on the corporate network. SAP-C02 scenarios frequently combine split-horizon with Resolver inbound endpoints so that on-prem users get the private view — this is the "on-prem AD users need to resolve AWS private endpoints" pattern.

Conditional Forwarding

Conditional forwarding is the on-prem counterpart to AWS Resolver Rules. It means the on-premises DNS server forwards queries for a specific domain suffix to a specific set of target DNS servers, while resolving everything else normally. For hybrid DNS resolver designs, conditional forwarding on the on-prem side mirrors the Resolver Rules on the AWS side.

The Full Round Trip

Consider a user at their corporate desk whose laptop's DNS is the on-prem BIND server at 10.1.1.53:

1. User browses to admin.internal.examhub.cc.
2. Laptop queries 10.1.1.53.
3. BIND evaluates its conditional forwarders: internal.examhub.cc → 10.0.1.10, 10.0.2.10 (the Resolver inbound endpoint ENIs).
4. BIND forwards the query to 10.0.1.10 over the VPN/DX.
5. The AWS inbound endpoint ENI hands the query to the in-VPC Resolver, which checks the PHZ for internal.examhub.cc and returns the private ALB IP.
6. The answer travels back over the same path to the laptop.

Conditional Forwarding on Both Sides

For a fully bi-directional hybrid DNS resolver:

• On-prem BIND/Windows DNS: forward internal.examhub.cc → inbound endpoint IPs.
• AWS Resolver Rule: forward corp.example.com → on-prem DNS IPs via outbound endpoint.

This is the bidirectional DNS forwarding pattern, and it is the most common correct answer for any SAP-C02 scenario that involves Active Directory on-prem plus AWS-hosted workloads.

DNSSEC Signing for Route 53

DNSSEC (DNS Security Extensions) cryptographically signs DNS records so that resolvers can verify the responses have not been tampered with in transit. Route 53 supports DNSSEC signing for public hosted zones (not PHZs — see the trap below).

How DNSSEC Signing Works in Route 53

1. Enable DNSSEC signing on a public hosted zone.
2. Route 53 creates a Key-Signing Key (KSK) backed by AWS KMS using a customer-managed key with the asymmetric ECC_NIST_P256 spec.
3. Route 53 also manages a Zone-Signing Key (ZSK) internally.
4. Route 53 signs every RRset in the zone with the ZSK and publishes DNSKEY, RRSIG, NSEC/NSEC3 records automatically.
5. You publish the DS (Delegation Signer) record at the parent zone (the TLD registrar) to establish the chain of trust.
6. Validating resolvers (like Cloudflare 1.1.1.1 or Google 8.8.8.8 with DNSSEC) verify the signature before returning the answer to the client.

DNSSEC Does Not Cover Private Hosted Zones

Route 53 DNSSEC signing is only available for public hosted zones. Private Hosted Zones are not signed because PHZs are only resolvable from associated VPCs via the Route 53 Resolver, which is an AWS-managed component — AWS treats the PHZ-to-Resolver path as a trusted channel. If you need validated resolution for internal names, you must use TLS (mTLS, private PKI) at the application layer.

Domain Registration vs DNSSEC

There are two related DNSSEC concepts:

• DNSSEC signing on Route 53 (above) — Route 53 acts as the signer.
• DNSSEC for domain registration — when your domain is registered through Route 53 Domains, you can upload the DS record to the TLD registry. This is the "other half" of the chain.

Why DNSSEC Matters for SAP-C02

Compliance and anti-hijack scenarios. If the question mentions regulated industries, government workloads, or "must prevent DNS spoofing," DNSSEC signing of the public hosted zone is the answer. If the question involves private names inside VPCs, DNSSEC is a distractor — offer PHZ and Resolver endpoints instead.

Resolver Query Logging (Resolver Query Log Config)

Route 53 Resolver Query Logging captures every DNS query that the Resolver processes for the associated VPCs and writes the log events to CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose. Logs include the query name, type, class, response code, source IP, and whether the query was answered from cache, from a PHZ, from a forwarding rule, or from public DNS.

Why Enable Query Logging?

• Security forensics — detect DNS exfiltration, DGA (domain generation algorithm) malware, or beaconing by inspecting query patterns.
• Compliance — many regulations (HIPAA, PCI, FedRAMP) require logs of DNS activity.
• Troubleshooting — diagnose why an EC2 instance is getting a stale or wrong answer.
• Cost attribution — identify runaway services doing millions of redundant lookups.

Configuration Objects

A Query Log Config is the central object. You create one Config pointing at a destination (CloudWatch Logs group, S3 bucket, or Firehose stream), and then you associate that Config with one or more VPCs. The same Config can cover many VPCs, and you can share a Config via AWS RAM to centralize logging across accounts.

What Is Logged vs Not

Resolver query logs capture queries handled by the VPC Resolver — this includes PHZ queries, public DNS queries, and outbound-forwarded queries. Queries answered on-prem (never reaching the VPC Resolver) are not captured — you would need on-prem logging for those. Queries arriving at an inbound endpoint from on-prem are captured because they pass through the VPC Resolver.

Cost

Billed per million queries logged, plus the destination's ingestion cost (CloudWatch Logs data ingestion, S3 PUT, Firehose throughput). Plan ahead: a chatty VPC can generate millions of queries per day.

Transit Gateway DNS Resolution over Peering

AWS Transit Gateway is the hub-and-spoke router that connects many VPCs, VPNs, and Direct Connect gateways. DNS over Transit Gateway is subtle because TGW is a layer-3 packet router, not a DNS-aware service.

TGW Does Not Resolve DNS

TGW forwards IP packets. If a VPC resolver sends a DNS query to an IP reachable only via TGW (for example, an inbound endpoint in the central Network VPC attached to the TGW), TGW carries that UDP/53 or TCP/53 packet transparently. TGW has no opinion on the payload.

The Shared-Service VPC Pattern

Most enterprise hybrid DNS resolver designs centralize inbound and outbound endpoints in a shared-service VPC (a.k.a. egress VPC or Network VPC):

+------------------+        +---------------------------+        +---------------+
|  Spoke VPC A     |------->|  Transit Gateway (TGW)   |<-------|  On-Prem DC   |
|  (resolver Rule  |        +---------------------------+        +---------------+
|   via RAM)       |                   ^
+------------------+                   |
                                       |
                              +------------------+
                              |  Network VPC     |
                              |  (inbound +      |
                              |   outbound EP)   |
                              +------------------+

Spoke VPCs receive the Resolver Rules via AWS RAM. When a spoke VPC queries corp.example.com, the rule says "forward to on-prem via outbound endpoint EP-1" — but EP-1 lives in the Network VPC, not the spoke. The spoke's VPC Resolver sends the forwarded query out through the spoke's route table, into the TGW, across the TGW to the Network VPC, and out EP-1 over the VPN/DX to on-prem. The response returns through the same path.

Route Table and TGW Attachment Requirements

• The Network VPC must be attached to the TGW.
• Each spoke VPC must be attached to the TGW with a route in its subnet route tables sending the outbound endpoint's ENI IP via the TGW.
• The Network VPC's subnet route table must send on-prem CIDRs via the VGW or VPN attachment.
• TGW route tables must permit traffic between spokes and the Network VPC.

TGW Peering Across Regions

TGW Peering creates a cross-Region connection between two TGWs. DNS still flows as packets over the peering — but the VPC Resolver in Region A cannot natively use an endpoint in Region B unless you route the query's IP through the peering. In most cases, you deploy a regional pair of Network VPCs (one per region), each with its own inbound/outbound endpoints, and point Resolver Rules at the local region's endpoint. Cross-region DNS over TGW peering is possible but usually unnecessary.

VPC Peering and DNS

VPC Peering alone does not enable cross-VPC resolution of PHZs or EC2 private hostnames unless you explicitly enable DNS resolution support for the peering. Even then, you still need to associate the PHZ with the peer VPC — peering only shares the network path, not the zone association.

Scenario: On-Prem AD Users Need to Resolve AWS Private Endpoints

This is the canonical SAP-C02 hybrid DNS resolver scenario. The requirements usually read:

Corporate employees authenticate via on-prem Active Directory. They need to access api.internal.examhub.cc, which is an internal ALB inside a private subnet of a VPC. DNS must not traverse the public internet. Provide a solution.

The Correct Architecture

1. Create a Private Hosted Zone for internal.examhub.cc with an alias record api.internal.examhub.cc → internal-alb.
2. Associate the PHZ with the VPC hosting the ALB.
3. Create a Resolver inbound endpoint in the same VPC with two ENIs across two AZs.
4. Ensure the Security Group on the inbound endpoint allows UDP/TCP 53 from the on-prem CIDR.
5. Ensure the VPC has a route back to on-prem via VPN/DX/TGW.
6. On the on-prem AD DNS servers, configure a conditional forwarder: internal.examhub.cc → inbound-endpoint-IPs.
7. Employees' laptops use the on-prem AD DNS as their resolver; queries for api.internal.examhub.cc flow laptop → AD DNS → inbound endpoint → in-VPC Resolver → PHZ → ALB IP → response all the way back.

Common Distractors

• "Enable DNSSEC on the PHZ" — wrong; PHZs cannot be DNSSEC-signed.
• "Share the PHZ via AWS RAM" — wrong; use VPC association authorization.
• "Use an outbound endpoint" — wrong direction; outbound is AWS → on-prem.
• "Use a public hosted zone with an internal subdomain" — wrong; exposes internal names to the internet.

Scenario: Shared Service VPC Hosting Central DNS

The second canonical scenario reads:

An AWS Organization has 30 accounts, each with multiple VPCs attached to a central Transit Gateway. All workloads need to resolve on-prem corp.example.com names. Design a cost-efficient, maintainable hybrid DNS resolver.

The Correct Architecture

1. In the Network account, create a shared service VPC attached to the Transit Gateway.
2. Deploy an outbound Resolver endpoint in that VPC (2 ENIs across 2 AZs).
3. Create a Resolver Rule: corp.example.com → on-prem-DNS-IPs via outbound endpoint.
4. Share the Resolver Rule via AWS RAM with the entire AWS Organization.
5. In each spoke account, associate the shared rule with the relevant VPCs.
6. TGW route tables permit spoke VPCs to reach the outbound endpoint ENIs in the Network VPC and on-prem CIDRs via the VGW.

Why It Wins

• One outbound endpoint across 30 accounts — saves 29 × $180/month = roughly $5,200/month.
• Single source of truth for forwarding rules — edit once, everyone sees the change.
• Decentralized association — each spoke chooses which of its VPCs use the rule.
• TGW-native — no VPC peering mesh, no duplicate endpoints.

Comparison Table: Hybrid DNS Resolver Mechanisms

Common Exam Traps for Hybrid DNS Resolver

1. Inbound vs outbound direction flipped — inbound is on-prem into AWS; outbound is AWS out to on-prem.
2. PHZ shared via RAM — wrong; use create-vpc-association-authorization / associate-vpc-with-hosted-zone.
3. DNSSEC enabled on PHZ — wrong; DNSSEC signing is public-zone only on Route 53.
4. VPC peering auto-resolves PHZ in peer VPC — wrong; you must associate the PHZ with the peer VPC and enable DNS resolution for the peering.
5. One outbound endpoint per spoke VPC — operational nightmare; centralize in a Network VPC and share Rules via RAM.
6. enableDnsHostnames or enableDnsSupport disabled — silent failure mode; both must be true for PHZ resolution.
7. TGW resolves DNS on your behalf — wrong; TGW only carries DNS packets, the Resolver does the resolution.
8. Forwarding rule for *.amazonaws.com — will be overridden by the System Rule; cannot break AWS-reserved domains.
9. Rely on public DNS for private names — insecure and slow; always use PHZ + inbound endpoint for hybrid access.
10. Use only an inbound endpoint for a bidirectional AD + AWS hybrid — you need both inbound and outbound endpoints for full two-way resolution.

Cost Optimization for Hybrid DNS Resolver

• Centralize endpoints: one pair of inbound + outbound endpoints in a Network VPC, reached via Transit Gateway, beats per-VPC duplication.
• Share Rules via RAM: eliminates duplicated outbound endpoints.
• Size Query Logging destinations carefully: CloudWatch Logs can get expensive at high QPS; route to Kinesis Firehose → S3 for cheaper long-term retention.
• Use PHZ aliases: alias records to AWS resources do not incur query charges on the alias lookup itself.
• Watch for runaway apps: a misbehaving application can do 1M+ DNS lookups per hour; Resolver Query Logs will surface this.

Security Considerations

• Resolver endpoint Security Groups should restrict port 53 source to on-prem CIDRs (for inbound) and destination to known on-prem DNS IPs (for outbound). An open 0.0.0.0/0 on port 53 turns your endpoint into an open resolver — a DDoS amplification risk.
• DNS query logging is a compliance control; retain logs per your regulatory regime.
• DNSSEC protects against cache poisoning on the public side; combine with TLS at the application layer for defense in depth.
• IAM permissions on Resolver Rules and PHZ operations should be tightly scoped; a misplaced route53:AssociateVPCWithHostedZone grant can leak internal names into untrusted VPCs.
• AWS PrivateLink endpoints used alongside hybrid DNS must have their private DNS feature enabled, and the VPC must have the enableDnsSupport flag true, or the PrivateLink DNS name will not override the public name.

Hybrid DNS Resolver vs Third-Party DNS Appliances

Some enterprises run Infoblox, BlueCat, or a bespoke BIND cluster as their authoritative internal resolver. The hybrid DNS resolver pattern still applies, but with Resolver Rules pointing at the appliance IPs instead of native AD DNS. The main trade-off:

• Route 53 Resolver endpoints + PHZ are fully managed, scale automatically, and integrate with AWS RAM and CloudWatch — but you pay for ENIs and queries.
• Third-party appliance offers centralized IPAM features and on-prem operational parity, but you run the cluster on EC2 and pay for instances, licenses, and patching.

SAP-C02 will usually frame the correct answer around the managed Route 53 Resolver pattern. Third-party appliance answers are often distractors unless the scenario explicitly calls out an existing DNS investment.

FAQ — Hybrid DNS Resolver on AWS

Q1: What is the difference between a Resolver inbound endpoint and an outbound endpoint?

An inbound endpoint allows DNS queries to flow from on-premises into the VPC Resolver, typically so on-prem servers can resolve Private Hosted Zone names. An outbound endpoint allows DNS queries to flow from the VPC Resolver out to on-premises, typically so EC2 instances can resolve on-prem private names. A fully bidirectional hybrid DNS resolver deploys both.

Q2: Can I share a Private Hosted Zone across AWS accounts using AWS RAM?

No. Private Hosted Zones are not shareable via AWS RAM. Use the two-step VPC Association Authorization workflow: the owner account runs create-vpc-association-authorization to authorize a specific VPC in another account, then the consumer account runs associate-vpc-with-hosted-zone to complete the association. AWS RAM handles Resolver Rules, Transit Gateways, and many other resources, but not PHZs.

Q3: Does Route 53 support DNSSEC for Private Hosted Zones?

No. Route 53 DNSSEC signing is available only for public hosted zones. Private Hosted Zones cannot be DNSSEC-signed because resolution happens through the trusted AWS-managed VPC Resolver, which AWS treats as an internal secure channel. For integrity guarantees on internal names, rely on application-layer TLS with AWS Private CA.

Q4: How do I centralize a hybrid DNS resolver across 30 AWS accounts?

Deploy a Network VPC in a dedicated Network account, attach it to a Transit Gateway, and create an outbound Resolver endpoint in that VPC along with the forwarding Resolver Rules for your on-prem domains. Share the Resolver Rules via AWS RAM with the entire AWS Organization. Each spoke account associates the shared rule with its own VPCs. For on-prem → AWS resolution, add an inbound endpoint in the same Network VPC and a conditional forwarder on the on-prem DNS server pointing at it.

Q5: What is the evaluation order for Resolver Rules in a VPC?

The Route 53 Resolver evaluates by longest-suffix match. If two rules have the same suffix length, System Rules (built-in, for AWS-reserved domains) take priority, followed by Auto-Defined Rules (installed when you associate a PHZ), followed by custom Forwarding Rules. In practice, most designs use distinct suffixes and the longest-match rule is unambiguous.

Q6: Does AWS Transit Gateway perform DNS resolution?

No. Transit Gateway is a layer-3 packet router. It forwards DNS packets (UDP/TCP port 53) between attached VPCs and on-prem networks, but it does not inspect, cache, or resolve DNS queries. DNS resolution is always performed by the Route 53 Resolver inside each VPC, optionally extended with Resolver endpoints.

Q7: Why does my VPC instance fail to resolve a PHZ name even though the PHZ is associated?

Check that both enableDnsHostnames and enableDnsSupport are set to true on the VPC. PHZ resolution silently fails when either flag is disabled. Also verify the VPC Resolver is being used — custom /etc/resolv.conf entries pointing at external DNS will bypass the Resolver entirely.

Q8: Can on-prem users resolve AWS PrivateLink endpoint DNS names?

Yes, with the right hybrid DNS resolver setup. PrivateLink endpoints create private DNS names under amazonaws.com. When the VPC has private DNS enabled on the endpoint, the VPC Resolver overrides the public DNS name with the endpoint's private IP. To let on-prem users inherit this behavior, deploy a Resolver inbound endpoint in the VPC and configure on-prem DNS to forward amazonaws.com subqueries (or at least the specific endpoint subdomains) to the inbound endpoint. Forwarding all of amazonaws.com is usually too broad; forward specific service subdomains you need privately.

Q9: What does a Resolver Query Log Config capture?

A Query Log Config captures every DNS query processed by the Route 53 Resolver in the associated VPCs, including the query name, type, source IP, response code, and the resolution path (PHZ, forwarding rule, public DNS). Logs can be written to CloudWatch Logs, S3, or Kinesis Firehose. The Config itself can be shared via AWS RAM across accounts for centralized logging.

Q10: When should I pick a third-party DNS appliance over Route 53 Resolver?

Usually only when you already operate a mature on-prem DNS/IPAM platform (Infoblox, BlueCat) and want identical tooling in AWS, or when you need features Route 53 does not offer (global views, rich IPAM, custom scripting on queries). For greenfield AWS designs or SAP-C02 exam scenarios, the answer is almost always Route 53 Resolver plus PHZ plus Resolver Rules shared via RAM — it is cheaper, fully managed, and integrates with AWS-native logging and IAM.

Summary — Hybrid DNS Resolver Cheat Sheet

• Inbound endpoint = on-prem → AWS VPC Resolver.
• Outbound endpoint = AWS VPC Resolver → on-prem.
• Resolver Rules forward queries; share them via AWS RAM to scale across accounts.
• Private Hosted Zones publish internal names; associate with VPCs, cross-account via VPC association authorization (not RAM).
• DNSSEC signing protects public zones only; not available for PHZ.
• Query Log Config audits Resolver activity; send to CloudWatch/S3/Firehose.
• Split-horizon DNS mixes public and private zones of the same name; PHZ wins inside associated VPCs.
• Conditional forwarding on the on-prem side mirrors AWS Resolver Rules; together they enable bidirectional hybrid resolution.
• Transit Gateway carries DNS packets but does not resolve; centralize endpoints in a Network VPC attached to the TGW.
• Two-endpoint, one-Network-VPC, RAM-shared-Rules is the canonical SAP-C02 architecture.

Put those nine lines on an index card and most SAP-C02 hybrid DNS resolver questions resolve themselves.