Hybrid DNS with Route 53 Resolver

Hybrid DNS is name-based routing

IP connectivity without name resolution still fails Active Directory joins, TLS certificate hostname checks, and service discovery. Amazon Route 53 VPC Resolver (formerly called Route 53 Resolver; AWS renamed it when Route 53 Global Resolver launched) already exists in every VPC. Instances query the VPC+2 address (for a 10.0.0.0/16 VPC that is 10.0.0.2). Resolver answers Amazon EC2 private DNS names, records in private hosted zones associated with the VPC, and public names via recursive lookups. It does not, by itself, know your on-premises Active Directory zone, and on-premises DNS does not, by itself, know those private hosted zones. Resolver endpoints and forwarding rules create the hybrid contract over Direct Connect or Site-to-Site VPN—never over a requirement that DNS leak across the public internet.

AWS also offers Route 53 Global Resolver for split-horizon and remote-client use cases that are not tied to a single VPC path. SAP-C02 Task 1.1 still centers on VPC Resolver endpoints for classic hybrid campuses. Mention Global Resolver only when the stem is about authorized clients resolving private zones from outside the VPC fabric; do not replace inbound/outbound endpoints with it in a standard Direct Connect Active Directory question.

Inbound endpoints: on-premises must find AWS names

An inbound endpoint is a set of elastic network interfaces in selected subnets. On-premises DNS servers (or other VPCs) send recursive or forwarded queries to those interface IP addresses. The inbound endpoint hands the query to VPC Resolver, which looks up associated private hosted zones and VPC DNS. Place inbound interfaces in at least two Availability Zones. Security groups on the interfaces must allow UDP and TCP port 53 from the on-premises resolver networks—not from 0.0.0.0/0 on the internet.

The private hosted zone must be associated with the VPC that hosts the inbound endpoint. A common outage is a beautifully documented zone associated only with spoke VPCs while on-premises queries land in a shared-services VPC that has no association. Associate the zone with the hub VPC and with every spoke that should resolve the name natively. Conditional forwarders on Windows DNS or forward stanzas on BIND should target the inbound IPs for only the AWS-owned zones (for example apps.internal or us-east-1.aws.example), not the entire corporate forest.

Inbound endpoints also help cross-Region resolution when a VPC in us-east-1 must resolve a private hosted zone that is associated with a VPC in us-west-2: the querier uses an outbound path toward the remote inbound endpoint, or you use native cross-Region private hosted zone association where that feature covers the case. Prefer association features first; use endpoints when the querier is not a VPC that can be associated.

Outbound endpoints and forwarding rules: AWS must find the datacenter

An outbound endpoint is the path from VPC Resolver to on-premises resolvers. You do not send all DNS through it. You create a forwarding rule for a domain name (and its subdomains) and attach that rule to VPCs. Queries for corp.example.com then leave through the outbound interfaces to the IP addresses of your domain controllers or DNS appliances. Queries for amazonaws.com and for private hosted zones that Resolver owns continue to be answered locally.

Forwarding rules can be shared with AWS RAM and associated with spoke VPCs in member accounts. That is the multi-account pattern: endpoints live in a centralized DNS or network VPC that has hybrid routing, rules are shared, spokes keep using VPC+2. Creating inbound and outbound endpoints in every spoke multiplies ENIs, security groups, and failure domains.

Target on-premises resolvers that are reachable over the same hybrid routing you already trust. If the outbound subnet has no route to the domain-controller CIDR via Transit Gateway or virtual private gateway, DNS fails even though “endpoints are green.” Do not point outbound rules at public recursive servers as a workaround for a missing Direct Connect route; that bypasses both security policy and split-horizon intent.

Private hosted zones in a hybrid estate

A private hosted zone is a Route 53 zone that Resolver answers only for associated VPCs (and for inbound queries that land in those VPCs). Use it for application records (api.payments.internal), split operational namespaces, and names you do not want on the public internet. Do not duplicate the entire Active Directory zone into Route 53 unless you have a deliberate migration off AD DNS. AD owns SRV records, site records, and dynamic updates; fighting AD with a parallel zone of the same name is how split-horizon incidents start.

When multiple accounts need the same zone, associate the zone with each VPC (Route 53 supports cross-account association authorization). Sharing a zone is not the same as sharing a Resolver rule. Spokes can resolve a shared zone through VPC+2 without outbound forwarding. On-premises still needs the inbound endpoint plus a conditional forwarder.

Active Directory as the usual enterprise scenario

A typical SAP-C02 hybrid AD design looks like this:

• On-premises (or AWS-hosted) domain controllers are authoritative for corp.example.com.
• AWS applications live in a distinct private hosted zone such as apps.example.internal or aws.example.com that AD does not own.
• Outbound rule: corp.example.com → domain controller IPs via outbound endpoints in two AZs.
• Inbound path: on-premises DNS conditionally forwards apps.example.internal to inbound endpoint IPs.
• VPC DHCP options remain the Amazon-provided DNS (VPC+2), not a hard-coded on-premises DNS server list. Hard-coding DC IPs in DHCP options creates a single hybrid dependency for every EC2 boot and breaks when you intended Resolver to answer private hosted zones.

If you must run domain controllers in AWS as well, those DCs still need reachability to on-premises DCs, and you still should not forward corp.example.com into a loop. AWS-hosted DCs are just additional AD DNS servers; they are not a reason to point VPC+2 at an inbound endpoint in the same VPC.

Split-horizon pitfalls

Split-horizon DNS means the same name (or parent zone) answers differently inside the campus than on the public internet. It is useful and dangerous.

Never forward amazonaws.com, aws.amazon.com, or the EC2 internal domain to on-premises. Those names must stay with VPC Resolver. Forwarding them is a popular “helpdesk workaround” that breaks instance metadata-adjacent name resolution, VPC endpoint private DNS, and package repositories that expect Amazon DNS.

Resolver endpoints scale by adding interfaces; AWS documents per-interface query capacity in the hybrid DNS guidance. Design dual-AZ first, then add interfaces when query volume or domain-controller placement requires it. Do not quote a stale QPS number in architecture reviews—check current AWS documentation for the endpoint you are using.

Scenario: AD plus application zone across accounts

A retailer has on-premises Active Directory corp.retail.example and three dozen spoke VPCs. Shared services in the network account host dual-AZ inbound and outbound endpoints on subnets that can route to the DCs over Transit Gateway. A private hosted zone pos.retail.internal holds point-of-sale API records and is associated with the hub VPC and every spoke. A RAM-shared forwarding rule sends corp.retail.example to the DC IPs. On-premises DNS forwards only pos.retail.internal to the inbound IPs. Developers who instead create an outbound rule for retail.example collide with a future PHZ under that parent and will take production DNS down during a “cleanup.” Keep the namespaces disjoint, keep DHCP on Amazon-provided DNS, and treat hybrid DNS as part of the same change control as Transit Gateway route tables.