A Route 53 Resolver endpoint isn’t just a bridge; it’s a stateful firewall and a dynamic redirector that actively manages DNS query direction based on its own internal ruleset, often leading to unexpected behavior if not precisely configured.
Let’s see this in action. Imagine you have an on-premises DNS server at 10.0.0.53 and you want your AWS VPC to be able to resolve records hosted on that server. You also have a public hosted zone in Route 53 for your domain, say example.com.
First, you’d create a VPC endpoint. This is a network interface within your VPC that Route 53 Resolver uses.
aws route53resolver create-resolver-endpoint \
--name "my-onprem-dns-resolver" \
--direction OUTBOUND \
--vpc-id vpc-0123456789abcdef0 \
--security-group-ids sg-0abcdef1234567890 \
--subnet-ids subnet-0123456789abcdef0,subnet-fedcba9876543210
The OUTBOUND direction means queries originating from your VPC will be sent to your on-premises DNS. The security group needs to allow outbound DNS traffic (UDP/TCP 53) to your on-premises IP. The subnets are where the endpoint’s network interfaces will live.
Next, you create a Resolver Rule to tell Route 53 when to send DNS queries to your on-premises server.
aws route53resolver create-resolver-rule \
--domain-name "onprem.example.com" \
--rule-type FORWARD \
--resolver-endpoint-id resolver-endpoint-abcdef1234567890 \
--target-ips Ip=10.0.0.53,Ipv6=
This rule says: "If a DNS query in this VPC is for a domain ending in onprem.example.com, forward it to the Resolver endpoint, which will then send it to 10.0.0.53."
Finally, you associate this rule with your VPC.
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rule-abcdef1234567890 \
--vpc-id vpc-0123456789abcdef0
Now, if an EC2 instance in vpc-0123456789abcdef0 tries to resolve server1.onprem.example.com, the query hits the Route 53 Resolver, sees the FORWARD rule for onprem.example.com, and sends it to the OUTBOUND endpoint. The endpoint then forwards it to your on-premises DNS at 10.0.0.53.
What about resolving www.example.com? If example.com is a public hosted zone managed by Route 53, and there’s no specific rule for it, the query will continue to be handled by the default VPC DNS resolver (which itself can query Route 53 public zones). The key is that Resolver rules are specific.
The surprise is how Route 53 Resolver handles DNS queries that don’t match any FORWARD rule. By default, if a query doesn’t match a FORWARD rule, it’s still processed by the Resolver. If the query is for a domain associated with a public Route 53 hosted zone, the Resolver will attempt to answer it directly. This means your VPC’s DNS resolution will try to hit your on-premises DNS and Route 53 public zones for the same domain if you’re not careful, potentially leading to inconsistent results or unexpected latency as it tries to resolve via both paths. This behavior is governed by the "System" resolver rule, which is always active and points to the AWS-provided DNS resolvers. If you have example.com in a public Route 53 zone and onprem.example.com forwarded to your on-prem DNS, a query for www.example.com will first go to Route 53 public, and only if that fails will it be considered for forwarding. However, if you have a FORWARD rule for example.com to your on-prem DNS, it will bypass Route 53 public entirely.
The mental model to build is one of prioritized query routing. Your VPC DNS first checks for any custom FORWARD rules. If a match is found, it uses that rule. If no custom rule matches, it falls back to the "System" rule, which directs queries for public Route 53 hosted zones to AWS’s public DNS infrastructure. This fallback is critical for hybrid setups; otherwise, you’d need explicit rules for every public domain you want to resolve.
The one thing most people don’t know is that an INBOUND Resolver endpoint is essentially a DNS server that AWS manages for you, listening within your VPC. When you send queries to its associated IP addresses from your on-premises network, it acts as a proxy, forwarding those queries to your VPC’s DNS. This is the reverse of the OUTBOUND scenario, enabling your on-premises machines to query AWS-hosted DNS records without needing to configure Route 53 public resolvers directly on them.
The next concept you’ll likely grapple with is controlling DNS resolution order between multiple custom FORWARD rules when domain names overlap.