Route 53 Resolver: hybrid DNS with inbound and outbound endpoints

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Create an inbound endpoint when on-premises DNS servers must resolve names held in AWS, such as private hosted zones. Create an outbound endpoint and forwarding rules when workloads in a VPC must resolve names held on-premises. Give each endpoint IP addresses in at least two Availability Zones, and do not associate a forwarding rule with the VPC that holds the inbound endpoint the rule forwards to, because that creates a query loop.

AWS now calls this service Route 53 VPC Resolver. It was previously named Route 53 Resolver and was renamed when Route 53 Global Resolver was introduced. This article uses "Resolver" for the VPC service.

Commands below come from the AWS CLI reference, or are assembled from its options and marked "written for this article". None was run in a lab. Addresses, IDs and domain names are placeholders.

Why it matters

This article assumes two naming authorities. Active Directory or an internal DNS platform holds the on-premises names, and Route 53 private hosted zones hold the AWS names. Each side needs a controlled path to the other.

The tempting shortcut is to point an on-premises forwarder at the VPC's base address plus two. AWS states that forwarding private DNS queries to any VPC CIDR + 2 address from on-premises or other VPC DNS servers is not supported and can cause unstable results, and recommends an inbound endpoint instead.

The other reason to get this right is reach. A forwarding rule applies to every VPC it is associated with, so one change can alter name resolution for many workloads at once.

How it works

Every VPC has Resolver available by default at the VPC CIDR base plus two, and at fd00:ec2::253 for IPv6. Endpoints add a path across the VPC boundary. Both kinds are sets of elastic network interfaces in subnets you choose.

Inbound endpoints come in two categories, Default and Delegation. A Default endpoint receives forwarded queries. A Delegation endpoint supplies IP addresses used as glue name server records, so that a subdomain in a private hosted zone can be delegated, and it supports Do53 only. Do53 is ordinary DNS on port 53. This article covers the Default type.

Three properties shape the design:

• Resolver is Regional. A rule needed in two Regions must be created in each.
• Endpoint IP addresses do not change for the life of the inbound endpoint, so on-premises forwarders can hold them. The exception is an interface in ACTION_NEEDED: its replacement is a new address, and every forwarder must learn it.
• The inbound and outbound endpoints can be in the same VPC or different VPCs in the Region. Any VPC can host them regardless of peering, but it needs network reach to on-premises.

How a rule is chosen

For each query, Resolver compares the name with the rules associated with the VPC the query came from. A rule matches when the names are identical or the query is a subdomain of the rule. The most specific match wins, so a rule for www.example.com beats one for example.com.

Rule types decide what happens next:

Resolver also creates autodefined rules. They cover each associated private hosted zone, AWS internal names when enableDnsHostnames is true, reverse lookups for private ranges and the VPC CIDR, and loopback names. A forward rule you create for the same domain overrides the autodefined one.

Two consequences follow:

1. A forward rule outranks a private hosted zone of the same name. AWS's example is a private zone example.com and a forward rule for example.com associated with one VPC: the rule takes precedence, and queries go to your network.
2. A matching private zone with no matching record returns NXDOMAIN rather than falling through to public DNS. In split-view designs, records that exist only in the public zone are invisible to associated VPCs.

What a "." rule does and does not take

A custom rule for "." still does not forward everything, because using a resolver outside AWS would break some functionality. The names held back are listed as autodefined rules. If you forward those excluded names as well, AWS warns that some features might stop working.

AWS also advises that if you forward "." or "com", you create a system rule for amazonaws.com, to improve performance and reduce forwarded queries and Resolver charges.

Build order

Build and test one direction at a time. The order below is an editorial recommendation.

1. Check the VPC settings

Private hosted zones need both enableDnsHostnames and enableDnsSupport set to true. Associate every private hosted zone that on-premises clients must resolve with the VPC holding the inbound endpoint. A zone that is correct for workloads in another VPC still returns the wrong answer to on-premises clients if this association is missing.

2. Create the security groups

AWS's recommended rules are:

These look loose for a reason. Security groups track connections unless the rules leave a flow untracked, and each endpoint interface can track only so many. AWS warns that with tracking enforced by restrictive rules, or with queries routed through a Network Load Balancer, the maximum can be as low as 1500 queries per second per IP address.

If you use DNS over HTTPS (DoH), AWS says you must also allow port 443 in the security group. If an outbound target listens on a custom port, change the egress rule to match.

Choose deliberately. Narrower rules may be right where query rates are modest and your security standard requires them, provided you size for the lower figure. Check with your own security team, and control who can reach the endpoint at the routing layer as well.

AWS states that you can't change the security group value after you create the endpoint, so decide first.

3. Create the endpoints

The CLI requires a request ID, security groups, a direction and IP addresses. Route 53 requires at least two addresses. AWS's high availability guidance is at least two Availability Zones, plus one more interface than you need if you need a given number available at all times.

Inbound, written for this article:

aws route53resolver create-resolver-endpoint \
  --name hybrid-inbound \
  --creator-request-id hybrid-inbound-20261110 \
  --security-group-ids sg-0aaaexample \
  --direction INBOUND \
  --ip-addresses SubnetId=subnet-0aaaexample,Ip=10.10.1.10 \
                 SubnetId=subnet-0bbbexample,Ip=10.10.2.10

Outbound, written for this article, with the optional one-minute metrics on:

aws route53resolver create-resolver-endpoint \
  --name hybrid-outbound \
  --creator-request-id hybrid-outbound-20261110 \
  --security-group-ids sg-0cccexample \
  --direction OUTBOUND \
  --ip-addresses SubnetId=subnet-0aaaexample,Ip=10.10.1.20 \
                 SubnetId=subnet-0bbbexample,Ip=10.10.2.20 \
  --rni-enhanced-metrics-enabled \
  --target-name-server-metrics-enabled

Those two flags are off by default and charged at standard CloudWatch rates. Target name server metrics are not supported on inbound endpoints.

Wait for the status to reach OPERATIONAL:

aws route53resolver get-resolver-endpoint \
  --resolver-endpoint-id rslvr-out-0example \
  --query 'ResolverEndpoint.Status'

An endpoint must always keep at least two addresses, which is why the replacement goes in first.

4. Point on-premises DNS at the inbound endpoint

Forward only the AWS-held domains to both inbound addresses. On Windows DNS, Add-DnsServerConditionalForwarderZone does this, written for this article:

Add-DnsServerConditionalForwarderZone -Name "aws.example.com" `
  -MasterServers 10.10.1.10,10.10.2.10 -PassThru

In BIND, a forward zone does the same, written for this article:

zone "aws.example.com" {
    type forward;
    forward only;
    forwarders { 10.10.1.10; 10.10.2.10; };
};

With forward only, BIND queries only the forwarders. The default of first lets the server look for the answer itself when the forwarders do not answer. As an editorial view, that suits a private name poorly.

Test from a host that can reach the endpoint. The dig @server name type form queries that server directly, and +tcp forces TCP:

dig @10.10.1.10 app.aws.example.com A
dig @10.10.2.10 app.aws.example.com A +tcp

5. Create and associate forwarding rules

Written for this article from the create-resolver-rule and associate-resolver-rule references:

aws route53resolver create-resolver-rule \
  --name corp-forward \
  --creator-request-id corp-forward-20261110 \
  --rule-type FORWARD \
  --domain-name corp.example.com \
  --resolver-endpoint-id rslvr-out-0example \
  --target-ips "Ip=10.20.1.53" "Ip=10.20.2.53"

aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-0example \
  --vpc-id vpc-0workloadexample

A rule can hold IPv4 or IPv6 targets but not both. Target IPs are the on-premises servers. The outbound endpoint's own addresses are in the VPC, and your on-premises firewall must allow queries from them.

Test from an instance in the associated VPC, using the default resolver, with dig host.corp.example.com A.

Do not associate this rule with the VPC holding an inbound endpoint if the rule's targets lead back to that endpoint, directly or through an on-premises server. AWS warns that the query can loop between the inbound and outbound endpoints. The rule can still be associated with other VPCs, and private zones on the hub still resolve through the inbound endpoint.

6. Share across accounts

Sharing a rule indirectly shares its outbound endpoint, so one outbound endpoint and one rule set can serve many accounts through AWS Resource Access Manager. In a shared VPC, an endpoint IP address can sit in a shared subnet only if the current account created the VPC, so that decides which account hosts the endpoints.

Two behaviours belong in your change process. Deleting or unsharing a rule makes the affected VPCs fall back to their remaining rules. Moving an account between Organizational Units deletes that account's associations with a rule shared to the old unit, unless the rule was already shared to the destination unit.

Sizing and limits

These quotas applied when checked. Use Service Quotas to confirm your own.

AWS says actual capacity varies with query type, response size, target health and response time, latency and protocol. A slow target server reduces capacity. Resolver also sends redundant outbound queries for each request, so outbound interface volume will not equal what clients send. AWS's trigger is to add interfaces if maximum rate exceeds 50% of capacity on any interface.

AWS's general approach is typically one inbound and one outbound endpoint per Region, adding IP addresses rather than endpoints. Billing is per endpoint IP address and per query processed.

A worked example, using hypothetical numbers and treating the published figures as a starting estimate only. Suppose peak demand is 6,000 queries per second and you plan to stay under 50%.

The second row exceeds the default of six addresses per endpoint. That is the practical price of tracked connections at this rate.

What the metrics say

Basic metrics in the AWS/Route53Resolver namespace arrive at five-minute intervals, which can hide a short burst. Alarm on these:

The fix depends on direction. For inbound endpoints load balancing is up to you, so a warning may be a hot spot: spread on-premises forwarders across all the addresses. Outbound traffic is balanced automatically, so a warning may come from a slow or failing target, and AWS says adding interfaces might not help until the target name server is fixed.

ResolverEndpointCapacityStatus and the RNI enhanced metrics can show gaps during interface maintenance. AWS recommends setting alarms to treat missing data as ignore, or using an evaluation period of more than five minutes.

Reading a query log

Query logging can record queries from associated VPCs, inbound queries and queries using outbound endpoints. It logs only unique queries, so an answer served from cache leaves no entry. A missing line is not proof that the query was never made.

Useful fields are query_name, rcode, answer_type, rdata, transport and srcids. In srcids, resolver_endpoint names the endpoint that passed the query to on-premises DNS. With CNAME chains that cross rules using different endpoints, only the last endpoint appears, so trace those by correlating logs.

What to choose and why

These are editorial recommendations.

Risks and limits

Warning: A broad forwarding rule, a "." rule, or a rule that overlaps a private hosted zone changes resolution for every associated VPC at once. Apply it to one non-production VPC first, and keep the disassociate command ready.

• Stale answers during an outage. Resolver may answer from cache beyond the TTL on timeouts, refused connections or SERVFAILs, so a name may appear to work during a fault.
• The 1024 packet limit. The link-local limit of 1024 packets per second per network interface applies to queries a busy instance sends to its local resolver, and includes other link-local services such as instance metadata. The linklocal_allowance_exceeded counter from ethtool shows it.
• Reverse lookups. Autodefined rules answer private-range reverse queries locally. If Active Directory or SSH relies on on-premises PTR records, turn off those rules for the VPC and create forward rules.
• Placement limits. Dedicated-tenancy VPCs cannot host endpoints, and Outposts subnets with a Local Network Interface are incompatible. Enabling that feature on a subnet stops the endpoint's interfaces.
• Scale of client addresses. Inbound interface capacity is affected above 40,000 unique IP and port combinations.
• Not tested here. All behaviour above comes from AWS, Microsoft and ISC documentation. Test in your own account before relying on it.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• What is Route 53 VPC Resolver?
• Resolving DNS queries between VPCs and your network
• How your network forwards queries to Resolver endpoints
• How Resolver forwards queries to your network
• Using rules to control query forwarding
• How rule matching works
• Autodefined system rules
• Choosing endpoint VPCs and considerations
• Resolver availability and scaling
• Resolver endpoint scaling
• Route 53 quotas
• Monitoring VPC Resolver with CloudWatch
• Private hosted zone considerations
• EC2 security group connection tracking
• AWS CLI route53resolver reference
• Add-DnsServerConditionalForwarderZone
• BIND 9 reference manual and manual pages

This article was originally published on 10 November 2026.