Amazon Route 53 Resolver endpoints connect the Amazon VPC DNS resolver with DNS servers outside the VPC resolver boundary. Inbound endpoints accept DNS queries from on-premises or connected networks into VPC Resolver. Outbound endpoints send selected VPC-originated DNS queries to DNS resolvers in on-premises networks or other reachable environments according to forwarding or delegation rules.<\/p>\n
Within AWS Architecture and Operations<\/a>, Resolver endpoints are the hybrid DNS bridge. The existing Route 53<\/a> and Secure DNS<\/a> articles provide the broader DNS model.<\/p>\n The key engineering decisions are direction, network reachability, endpoint IP\/AZ placement, protocols, rule scope, shared-VPC\/account architecture, and observability.<\/p>\n An inbound endpoint has private IP addresses in subnets you choose.<\/p>\n On-premises DNS resolvers forward selected domains to those endpoint IPs over Direct Connect or VPN-connected network paths.<\/p>\n VPC Resolver can then answer private hosted-zone and supported AWS DNS names visible to the endpoint\/VPC context.<\/p>\n Route 53 Resolver now supports inbound delegation endpoints for delegating DNS authority for a subdomain to VPC Resolver.<\/p>\n On-premises authoritative DNS uses NS\/glue records pointing at the inbound delegation endpoint addresses.<\/p>\n Delegation follows DNS authority semantics instead of merely forwarding every query matching a configured suffix.<\/p>\n An outbound endpoint also uses private IP addresses in selected subnets and needs network connectivity to the target DNS servers.<\/p>\n Resolver rules decide which domains are forwarded and to which target IP addresses.<\/p>\n The same outbound endpoint can serve multiple associated VPCs in the same Region, reducing the need to deploy a DNS appliance in each VPC.<\/p>\n A forwarding rule matches a domain suffix and forwards queries directly to configured target resolver IPs.<\/p>\n An outbound delegation rule respects DNS delegation records and delegates only when returned NS records match the configured delegated name servers.<\/p>\n Use forwarding for conditional DNS resolution and delegation when the organization wants to preserve authoritative DNS delegation semantics.<\/p>\n Resolver selects rules based on the most specific matching domain, with system\/autodefined and custom-rule behavior documented by AWS.<\/p>\n A broad Keep rule hierarchy small and documented; overlapping rules are a common cause of \u201cworks in one VPC, fails in another\u201d DNS incidents.<\/p>\n Resolver endpoint network interfaces use security groups that need the appropriate inbound or outbound rules.<\/p>\n Traditional DNS requires UDP\/TCP 53; current Resolver endpoint APIs also support DNS-over-HTTPS variants for supported inbound\/outbound endpoints.<\/p>\n Delegation inbound endpoints currently use Do53 only, so protocol selection should match the endpoint direction and the external resolver capabilities.<\/p>\n Production Resolver endpoints should have IP addresses in more than one subnet\/AZ so one AZ impairment does not remove the hybrid DNS path.<\/p>\n External DNS servers should be configured with all inbound endpoint addresses, and outbound rules should target redundant external DNS servers.<\/p>\n Test loss of one endpoint IP and one target resolver; DNS retry behavior can increase latency even when another path eventually succeeds.<\/p>\n AWS documents that Resolver can choose target IPs randomly and retry another target when one does not respond.<\/p>\n Do not configure a slow or standby DNS server as a target expecting it to receive traffic only after the primary fails.<\/p>\n Every configured target should be healthy, reachable, and capable of answering the delegated\/forwarded zone normally.<\/p>\n Resolver rules can be shared across accounts through AWS Resource Access Manager, enabling a centralized networking account to manage domain-forwarding policy for many VPCs.<\/p>\n Centralization reduces drift but increases policy blast radius.<\/p>\n Use change review, staged associations, and clear ownership so one new broad rule cannot redirect DNS for the whole organization unexpectedly.<\/p>\n Resolver query logging can record VPC-originated queries, inbound endpoint queries, outbound endpoint queries, and DNS Firewall activity.<\/p>\n Logs include query name\/type, source identity\/IP where available, response code, and response data.<\/p>\n Use logs to distinguish NXDOMAIN\/ServFail, wrong rule selection, unreachable target, private-zone mismatch, and application-side cache behavior.<\/p>\n The mature design uses redundant endpoint IPs, correct network\/security groups, deliberate forwarding\/delegation rules, healthy external resolvers, centralized sharing where appropriate, and query logging.<\/p>\n Hybrid DNS should let each namespace be answered by the right authority without creating recursive loops, hidden single points of failure, or one-off resolver appliances in every VPC.<\/p>\n Endpoint IP capacity should be monitored in high-query environments. Resolver endpoints scale based on the IP addresses assigned to them, and DNS query volume\/connections can make one small endpoint set a bottleneck. Add IP addresses\/AZs according to current service quotas and observed QPS rather than treating the initial two addresses as permanently sufficient.<\/p>\n Security groups should restrict DNS sources\/targets to known resolver networks. An inbound endpoint should not accept DNS from arbitrary connected CIDRs; an outbound endpoint should only reach approved target resolver addresses\/ports. This reduces the chance the endpoint becomes an unintended recursive DNS path across connected networks.<\/p>\n Hybrid name-resolution architecture should avoid forwarding loops. If on-premises forwards Private hosted zone associations are part of inbound behavior. An inbound endpoint can answer only names visible through the VPC Resolver context, including private hosted zones associated with the VPC and resolver rules. If the endpoint VPC is not associated with the expected zone, forwarding from on-premises can reach AWS successfully and still return NXDOMAIN.<\/p>\n DNS Firewall and Resolver rules can work together, but policy order should be understood. Query logs can include DNS Firewall actions, and a central DNS architecture may share firewall rule groups and forwarding rules through Profiles\/RAM. Treat domain security policy and hybrid forwarding as separate layers so a block is not mistaken for a routing failure.<\/p>\n DoH support changes transport but not namespace authority. Current endpoints can support Do53 and\/or DoH in supported directions, while inbound delegation is Do53-only. Use DoH when encrypted resolver transport is required and compatible; do not expect it to solve split-horizon, forwarding-loop, or ownership problems.<\/p>\n Centralized Resolver endpoints can become shared infrastructure across many accounts. Deploy them in dedicated networking VPCs with resilient Direct Connect\/VPN paths, clear capacity ownership, and cross-account rule sharing. Avoid every application team creating its own endpoints because duplicate DNS bridges are expensive and can produce inconsistent namespace routing.<\/p>\n Monitoring should alert on SERVFAIL\/timeout spikes, target resolver health, endpoint QPS, security-group\/network changes, and rule association drift. Correlate query logs with on-premises DNS logs when possible so a hybrid incident can trace one name from client through forwarding rule to authoritative answer.<\/p>\n Rule sharing through RAM should have a central change process and local visibility. Application accounts need to know which shared Resolver rules affect their VPCs and who owns them. A centralized DNS team should provide a catalog of domains, targets, associations, and maintenance windows so teams do not create conflicting local rules.<\/p>\n DNS TTLs and negative caching matter during migrations. Moving a private zone or changing forwarding targets can leave clients using cached positive or NXDOMAIN responses after the resolver path has been corrected. Include authoritative and resolver cache timing in cutover plans and troubleshooting expectations.<\/p>\n Endpoints require route-table connectivity as well as security groups. Direct Connect\/VPN\/TGW paths to on-premises DNS servers must exist from the endpoint subnets, and return routes must reach the endpoint IPs. A resolver target can be allowed by SG and still time out because the hybrid network path is missing or asymmetric.<\/p>\n Resolver endpoints should be treated as shared critical infrastructure with IaC, tagging, alarms, and change history. DNS outages often affect authentication, service discovery, package repositories, and databases at once, so endpoint\/rule changes deserve a blast-radius review comparable to routing or firewall changes.<\/p>\n Resolver Profiles can simplify organization-wide reuse by grouping private hosted zone associations, Resolver rules, and DNS Firewall rule groups into a named configuration that can be shared\/associated according to current Route 53 capabilities. Where Profiles fit the organization, they can reduce separate association workflows, but centralization increases the need for careful version\/change governance.<\/p>\n Endpoint protocol selection should be driven by trust and compatibility. DNS-over-HTTPS can protect resolver transport on supported endpoint directions, while traditional Do53 remains widely compatible and is required for inbound delegation. DoH does not encrypt the DNS answer once the application receives it or replace end-to-end application TLS; it protects only the resolver transport hop.<\/p>\n Hybrid DNS disaster recovery should include secondary network connectivity. Two inbound endpoint IPs in separate AZs do not help if both depend on one Direct Connect circuit or one on-premises resolver cluster. Test VPN\/secondary DX paths and alternate resolver targets so the namespace remains reachable when the primary hybrid connection fails.<\/p>\n","protected":false},"excerpt":{"rendered":" Amazon Route 53 Resolver endpoints connect the Amazon VPC DNS resolver with DNS servers outside the VPC resolver boundary. Inbound endpoints accept DNS queries from on-premises or connected networks into VPC Resolver. Outbound endpoints send selected VPC-originated DNS queries to DNS resolvers in on-premises networks or other reachable environments according to forwarding or delegation rules. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19919","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tInbound endpoints let external resolvers query VPC Resolver<\/h3>\n
Inbound delegation is different from ordinary forwarding<\/h3>\n
Outbound endpoints send VPC queries to external resolvers<\/h3>\n
Forwarding rules and delegation rules solve different problems<\/h3>\n
Rule specificity determines which resolver path wins<\/h3>\n
example.com<\/code> rule and a more-specific corp.example.com<\/code> rule can direct queries differently.<\/p>\nEndpoint security groups must permit the DNS protocols<\/h3>\n
Use multiple endpoint IPs across Availability Zones<\/h3>\n
Outbound target selection is not active\/passive preference<\/h3>\n
Share rules rather than duplicating hybrid DNS everywhere<\/h3>\n
Resolver query logging provides the evidence needed for troubleshooting<\/h3>\n
Resolver endpoints succeed when hybrid DNS has a clear authority and failure model<\/h3>\n
corp.example.com<\/code> to AWS while AWS forwards the same suffix back on-premises, queries can recurse until timeout. Maintain one authority map for every private namespace and test resolution paths from both sides whenever rules change.<\/p>\n