This chapter covers AWS Route 53 Resolver for hybrid DNS, a critical service for resolving DNS queries between on-premises networks and Amazon VPCs. For the SOA-C02 exam, this topic appears in 5-10% of questions, primarily in the Networking domain (Objective 5.2). You will learn how Route 53 Resolver works, its components (inbound/outbound endpoints, forwarding rules), configuration steps, and common troubleshooting scenarios. Mastering this topic is essential for SysOps administrators managing hybrid cloud architectures.
Jump to a section
Imagine a large company with headquarters (HQ) in New York and branch offices in London, Tokyo, and Sydney. Each office has its own internal phone directory (DNS) that maps employee names to internal extensions. Employees in different offices need to call each other by name, but each office's directory is separate and uses different numbering plans (e.g., HQ uses 4-digit extensions, London uses 5-digit extensions). To enable cross-office calling, the company installs a 'phone bridge' (Route 53 Resolver) at each office. When an employee in New York dials 'John Smith' (a name in London's directory), the New York phone system cannot resolve it locally. Instead, it sends the query to the New York phone bridge, which forwards it over a secure private line (VPN/Direct Connect) to the London phone bridge. London's bridge looks up 'John Smith' in its local directory, finds the extension 56789, and sends the answer back. The New York bridge caches that mapping for 60 seconds (default TTL) so if another employee calls John Smith soon, it answers instantly without going to London. However, if John Smith moves to Tokyo, the London directory is updated, but the New York cache still has the old mapping until it expires. The phone bridge also supports reverse lookup: if a call comes in from an external number, the bridge can query the HQ directory to find which employee that number belongs to. This system allows seamless name resolution across all offices while keeping each office's directory autonomous and secure.
What is Route 53 Resolver and Why It Exists
Route 53 Resolver is a regional AWS service that enables DNS resolution across hybrid networks. By default, each Amazon VPC has a DNS resolver (the VPC+2 IP, e.g., 10.0.0.2) that can resolve public DNS names and private hosted zones within the VPC. However, it cannot resolve on-premises DNS names unless you configure conditional forwarding. Route 53 Resolver bridges this gap by allowing you to forward DNS queries from your VPC to on-premises DNS servers and vice versa.
The service consists of three main components: - Inbound Endpoint: Exposes Route 53 Resolver inside your VPC, allowing on-premises DNS servers to forward queries to AWS. - Outbound Endpoint: Allows VPC resources to forward DNS queries to on-premises DNS servers. - Forwarding Rules: Define which domain names are forwarded to which target DNS servers.
How It Works Internally
When an EC2 instance in a VPC needs to resolve a hostname like 'app.corp.local', it sends a DNS query to the VPC resolver (e.g., 10.0.0.2). The VPC resolver checks if the domain matches a forwarding rule. If it does, the query is forwarded to the outbound endpoint, which sends it over a VPN or Direct Connect connection to the on-premises DNS server. The response is cached and returned to the instance.
Similarly, an on-premises server can query 'db.internal.aws' by sending the query to the inbound endpoint's IP addresses (two Elastic Network Interfaces in different subnets for high availability). The inbound endpoint forwards the query to the VPC resolver, which resolves it using Route 53 private hosted zones.
Key Components, Values, Defaults, and Timers
Endpoint Types: Inbound and Outbound. Each endpoint must be created in at least two subnets in different Availability Zones for high availability. Each endpoint uses an Elastic Network Interface (ENI) with a private IP from the subnet.
Forwarding Rules: Rules are associated with a Resolver rule and specify a domain name (e.g., 'corp.local') and target IP addresses (on-prem DNS servers). Rules can be shared across accounts via AWS RAM.
TTL: Route 53 Resolver caches DNS responses. The default TTL is 60 seconds, but it respects the TTL from the authoritative DNS server. You can configure a custom TTL for forwarding rules (minimum 0, maximum 86400 seconds).
Query Logs: You can enable DNS query logging to CloudWatch Logs to monitor and troubleshoot DNS queries.
Limits:
Max inbound endpoints per region: 5 (soft limit, can be increased).
Max outbound endpoints per region: 5.
Max forwarding rules per outbound endpoint: 1000.
Max forwarding rules per rule: 1 (a rule is a single mapping).
Protocol: DNS over UDP (port 53) and TCP (port 53) for large responses. Route 53 Resolver supports EDNS0 for larger UDP payloads.
Configuration and Verification Commands
Creating an inbound endpoint via AWS CLI:
aws route53resolver create-resolver-endpoint \
--creator-request-id unique-string \
--security-group-ids sg-12345678 \
--direction INBOUND \
--ip-addresses SubnetId=subnet-abc,SubnetId=subnet-defCreating an outbound endpoint:
aws route53resolver create-resolver-endpoint \
--creator-request-id unique-string \
--security-group-ids sg-87654321 \
--direction OUTBOUND \
--ip-addresses SubnetId=subnet-ghi,SubnetId=subnet-jklCreating a forwarding rule:
aws route53resolver create-resolver-rule \
--creator-request-id unique-string \
--rule-type FORWARD \
--domain-name corp.local \
--target-ips Ip=192.168.1.10,Port=53 Ip=192.168.1.11,Port=53 \
--resolver-endpoint-id rslvr-out-123456789Associating a rule with a VPC:
aws route53resolver associate-resolver-rule \
--resolver-rule-id rslvr-rr-123456789 \
--vpc-id vpc-12345678Verification commands:
- dig @10.0.0.2 app.corp.local from an EC2 instance to test forwarding.
- nslookup db.internal.aws <inbound-endpoint-ip> from on-premises to test inbound resolution.
- Check CloudWatch Logs for query logs.
Interaction with Related Technologies
AWS Direct Connect: Provides a dedicated private connection for DNS traffic, reducing latency and improving reliability compared to VPN.
AWS Site-to-Site VPN: Can be used for DNS forwarding, but adds encryption overhead and potential latency.
Route 53 Private Hosted Zones: Used to define DNS records for internal AWS resources (e.g., RDS, ELB). These are resolved by the VPC resolver and can be made available on-premises via inbound endpoints.
AWS RAM: Allows sharing forwarding rules across accounts, enabling centralized DNS management.
Security Groups: Control traffic to/from endpoints. Inbound endpoints must allow UDP/TCP port 53 from on-premises IPs. Outbound endpoints must allow UDP/TCP port 53 to on-premises DNS servers.
VPC Flow Logs: Can be used to verify DNS traffic is flowing through the endpoints.
Common Configurations
Scenario 1: On-premises to AWS - Create an inbound endpoint in VPC A. - Configure on-premises DNS to forward queries for 'aws.internal' to the inbound endpoint IPs. - In Route 53, create a private hosted zone for 'aws.internal' with records for AWS resources.
Scenario 2: AWS to on-premises - Create an outbound endpoint in VPC B. - Create a forwarding rule for 'corp.local' pointing to on-premises DNS servers. - Associate the rule with VPC B. - Now EC2 instances in VPC B can resolve 'app.corp.local'.
Scenario 3: Multi-account hybrid DNS - Use AWS RAM to share forwarding rules across accounts. - Each account's VPC can associate the shared rule. - Centralized management of DNS forwarding.
Performance Considerations
Use multiple endpoints in different AZs for HA.
Consider using EDNS0 to avoid TCP fallback.
Monitor query logs for high latency or failures.
For high query volumes, increase the number of endpoints (soft limit).
Use TTL appropriately to reduce load on on-premises DNS.
Troubleshooting
DNS resolution fails: Check security group rules (port 53 UDP/TCP). Verify network connectivity (VPN/Direct Connect is up). Check that the forwarding rule is associated with the correct VPC.
Inbound endpoint not responding: Ensure the endpoint's ENIs have proper route table entries (route to on-premises via VPN/Direct Connect).
Cached stale records: Lower TTL or manually flush cache (no AWS CLI command; you must wait for TTL expiry).
Query logs show no data: Ensure logging is enabled and the CloudWatch Logs group exists.
Create an Inbound Endpoint
Navigate to Route 53 > Resolver > Inbound endpoints. Click 'Create inbound endpoint'. Provide a name (e.g., 'corp-inbound'), select the VPC, and specify at least two subnets in different Availability Zones. For each subnet, an Elastic Network Interface (ENI) will be created with a private IP. You must also assign a security group that allows UDP/TCP port 53 from your on-premises DNS server IPs. The endpoint will be provisioned in a few minutes. Once created, note the two IP addresses (one per ENI). These IPs are the targets for your on-premises DNS forwarders.
Configure On-Premises DNS Forwarders
On your on-premises DNS servers (e.g., Windows Server DNS, BIND), create a conditional forwarder for the domain you want to resolve in AWS (e.g., 'aws.internal'). Point the forwarder to the two IP addresses of the inbound endpoint. Ensure the on-premises servers can reach those IPs over the VPN or Direct Connect connection. Test by running 'nslookup db.aws.internal <inbound-ip>' from an on-premises machine. If successful, you should get the private IP of the RDS instance.
Create an Outbound Endpoint
In the same AWS region, create an outbound endpoint. Provide a name, select the VPC, and choose at least two subnets in different AZs. Assign a security group that allows outbound UDP/TCP port 53 to your on-premises DNS server IPs. The endpoint will get two ENIs with private IPs. Note these IPs; they are the source IPs for outbound DNS queries from AWS to on-premises.
Create Forwarding Rules for On-Premises Domains
Create a resolver rule of type FORWARD. Specify the domain name (e.g., 'corp.local') and the target IPs of your on-premises DNS servers (e.g., 192.168.1.10, 192.168.1.11). Associate this rule with the outbound endpoint you created. Then associate the rule with the VPC(s) that need to resolve on-premises names. You can also share the rule via AWS RAM for multi-account setups. Once associated, EC2 instances in the VPC can resolve 'app.corp.local' by sending queries to the VPC resolver.
Associate Forwarding Rules with VPCs
After creating the forwarding rule, you must associate it with one or more VPCs. This can be done via the console, CLI, or AWS RAM. The association tells the VPC resolver to forward queries for the specified domain to the outbound endpoint. You can associate multiple rules with the same VPC. For example, you could have rules for 'corp.local', 'example.local', and 'internal.example.com'. Each rule is independent. Once associated, the VPC resolver will check the domain against all associated rules and forward matching queries.
Test and Verify DNS Resolution
From an EC2 instance in the VPC, run 'dig app.corp.local @169.254.169.253' (the VPC resolver IP) or simply 'nslookup app.corp.local'. If configured correctly, you should receive the on-premises IP address. Check CloudWatch Logs for query logs to see the forwarded query and response. Also test the reverse direction: from on-premises, query the inbound endpoint IP for an AWS private hosted zone record. Use 'nslookup db.aws.internal <inbound-ip>'. Both directions should work. If not, check security groups, route tables, and network connectivity (VPN/Direct Connect).
Enterprise Scenario 1: Global Retail Chain with Hybrid DNS
A multinational retail company operates data centers in the US and Europe, with AWS VPCs in us-east-1 and eu-west-1. They use Active Directory DNS for internal domain 'corp.retail.com'. The company wants EC2 instances in AWS to resolve on-premises application servers (e.g., 'erp.corp.retail.com') and on-premises servers to resolve AWS RDS endpoints (e.g., 'orders-db.aws.retail.com'). They set up Route 53 Resolver inbound and outbound endpoints in each region. The outbound endpoint forwards 'corp.retail.com' to on-premises DNS servers. The inbound endpoint allows on-premises DNS to forward 'aws.retail.com' to AWS. They also use AWS RAM to share forwarding rules across their multiple AWS accounts. In production, they handle 5000 DNS queries per second. They monitor query logs in CloudWatch for anomalies. A common issue is stale DNS caches; they set TTL to 300 seconds for forwarding rules to balance freshness and performance. Misconfiguration often occurs when security groups are too restrictive (e.g., missing UDP port 53) or when route tables do not include the VPN/Direct Connect path for the endpoint ENIs.
Enterprise Scenario 2: Financial Services with Strict Compliance
A bank uses a hub-and-spoke VPC architecture with a central shared services VPC. They need to resolve on-premises DNS names from all spoke VPCs. They create outbound endpoints in the hub VPC and share the forwarding rules via AWS RAM to each spoke VPC. The on-premises DNS servers are behind a firewall that only allows traffic from specific source IPs. They configure the outbound endpoint's ENI IPs as allowed sources. For inbound resolution, they create inbound endpoints in the hub VPC and point on-premises conditional forwarders to those IPs. The bank also enables DNS query logging for audit purposes. A frequent problem is that the on-premises firewall blocks DNS responses because the source port is not 53; they must allow ephemeral ports. Another issue is that the VPC resolver's default TTL (60s) causes excessive queries to on-premises; they increase the TTL in the forwarding rule to 600s to reduce load.
Common Pitfalls
Security Group Misconfiguration: Forgetting to allow inbound UDP/TCP 53 from on-premises IPs on the inbound endpoint, or outbound UDP/TCP 53 to on-premises on the outbound endpoint.
Route Tables: The subnets where endpoints are deployed must have routes to the on-premises network via VPN/Direct Connect. If missing, traffic is dropped.
VPC Resolver IP: The VPC resolver IP (VPC+2) is used by instances; forwarding rules are applied there. If an instance uses a custom DNS server (e.g., 8.8.8.8), forwarding rules are bypassed.
CNAME Resolution: Route 53 Resolver does not follow CNAMEs across domains unless the target domain is also forwarded. For example, if 'app.corp.local' is a CNAME to 'app.aws.internal', the resolver will try to resolve 'app.aws.internal' using the VPC resolver (not forwarded) unless you have a rule for 'aws.internal' as well.
Objective 5.2: Configure DNS and content delivery on AWS
This chapter directly supports SOA-C02 exam objective 5.2, specifically the subtopic 'Configure Route 53 Resolver for hybrid networks'. Exam questions test your ability to design and troubleshoot hybrid DNS architectures.
Common Wrong Answers and Why Candidates Choose Them
'Use a VPC Peering connection instead of Route 53 Resolver' – Candidates think VPC Peering provides DNS resolution, but VPC Peering only supports DNS resolution for private hosted zones if the VPCs are in the same account and region. For hybrid (on-premises), Route 53 Resolver is required.
'Create a forwarding rule without an outbound endpoint' – Candidates assume the VPC resolver can directly forward to on-premises. However, forwarding rules must be associated with an outbound endpoint; without it, the rule does nothing.
'Use the same security group for both inbound and outbound endpoints' – Security group rules differ: inbound endpoints need inbound port 53 from on-premises; outbound endpoints need outbound port 53 to on-premises. Using the same group may block traffic.
'DNS queries from on-premises to AWS use the outbound endpoint' – The inbound endpoint handles on-premises-to-AWS queries. The outbound endpoint handles AWS-to-on-premises queries.
Specific Numbers and Terms on the Exam
Default TTL: 60 seconds (but can be overridden).
Endpoint IPs: Two ENIs in different AZs.
Ports: UDP 53 (primary), TCP 53 (fallback for large responses).
Maximum forwarding rules per outbound endpoint: 1000.
Maximum inbound/outbound endpoints per region: 5 (soft limit).
The VPC resolver IP is always the VPC CIDR +2 (e.g., 10.0.0.2).
Edge Cases and Exceptions
If the on-premises DNS server is unreachable, the VPC resolver returns NXDOMAIN immediately (no fallback).
Route 53 Resolver does not support DNS over HTTPS (DoH) or DNS over TLS (DoT).
Private hosted zones are only resolvable within the VPC they are associated with. To make them accessible from on-premises, you must use an inbound endpoint.
Forwarding rules are regional; you must create endpoints in each region where you need hybrid DNS.
How to Eliminate Wrong Answers
If a question asks about resolving on-premises names from AWS, look for 'outbound endpoint' and 'forwarding rule'.
If a question asks about resolving AWS private hosted zones from on-premises, look for 'inbound endpoint'.
If a question mentions 'shared services' or 'multiple accounts', think of AWS RAM for sharing rules.
If a question mentions 'high availability', ensure endpoints are in at least two AZs.
Route 53 Resolver has two endpoint types: inbound (on-premises to AWS) and outbound (AWS to on-premises).
Forwarding rules must be associated with an outbound endpoint and then associated with a VPC to take effect.
Inbound endpoints expose two ENI IPs in different AZs for high availability; on-premises DNS forwarders must target these IPs.
Default TTL for cached responses is 60 seconds; you can override it in forwarding rules (0-86400 seconds).
Route 53 Resolver only supports UDP/TCP port 53; no DoH or DoT.
Security groups must allow the correct direction of traffic: inbound endpoint needs inbound 53, outbound endpoint needs outbound 53.
Forwarding rules can be shared across accounts using AWS RAM, enabling centralized DNS management.
DNS query logging to CloudWatch is essential for troubleshooting and auditing.
Route 53 Resolver is regional; you must create endpoints in each region where hybrid DNS is needed.
The VPC resolver IP (VPC CIDR +2) is used by instances; forwarding rules are applied at this resolver.
These come up on the exam all the time. Here's how to tell them apart.
Route 53 Resolver Outbound Endpoint
Forwards DNS queries to on-premises DNS servers over VPN/Direct Connect.
Requires explicit forwarding rules for each domain.
Supports hybrid (on-premises + AWS) DNS resolution.
Can be shared across accounts via AWS RAM.
Works across different regions (endpoints are regional).
VPC Peering with DNS Resolution
Only resolves private hosted zones between peered VPCs (same account/region).
Does not require forwarding rules; uses VPC resolver automatically.
Does not support on-premises DNS resolution.
Cannot be shared across accounts (peering is per-account).
Only works within the same region (inter-region peering does not support DNS resolution).
Route 53 Resolver Inbound Endpoint
Receives DNS queries from on-premises DNS servers.
Resolves queries using VPC resolver (private hosted zones, public DNS).
Requires security group inbound rule for UDP/TCP 53 from on-premises.
Used for on-premises-to-AWS DNS resolution.
ENI IPs are the target for on-premises conditional forwarders.
Route 53 Resolver Outbound Endpoint
Sends DNS queries from VPC to on-premises DNS servers.
Resolves queries using on-premises DNS servers (via forwarding rules).
Requires security group outbound rule for UDP/TCP 53 to on-premises.
Used for AWS-to-on-premises DNS resolution.
ENI IPs are the source of outbound queries.
Mistake
Route 53 Resolver can resolve any on-premises DNS name without explicit forwarding rules.
Correct
The VPC resolver only resolves public DNS and private hosted zones associated with the VPC. To resolve on-premises names, you must create forwarding rules and associate them with an outbound endpoint.
Mistake
You need only one endpoint (inbound or outbound) for both directions.
Correct
Inbound and outbound endpoints are separate. Inbound endpoints handle queries from on-premises to AWS; outbound endpoints handle queries from AWS to on-premises. Both are needed for bidirectional resolution.
Mistake
Route 53 Resolver supports DNS over HTTPS (DoH).
Correct
Route 53 Resolver only supports standard DNS over UDP (port 53) and TCP (port 53). It does not support DoH or DoT.
Mistake
Forwarding rules are automatically applied to all VPCs in the account.
Correct
Forwarding rules must be explicitly associated with each VPC. You can use AWS RAM to share rules across accounts, but association is still required.
Mistake
The VPC resolver IP (169.254.169.253) can be used as a DNS forwarder for on-premises servers.
Correct
The VPC resolver IP is only reachable from within the VPC. On-premises servers cannot directly query it. They must use the inbound endpoint IPs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An inbound endpoint allows on-premises DNS servers to forward DNS queries to AWS. It provides IP addresses (ENIs) that on-premises conditional forwarders target. An outbound endpoint allows AWS resources (via VPC resolver) to forward DNS queries to on-premises DNS servers. It works with forwarding rules to specify which domains to forward. Both are required for bidirectional hybrid DNS.
No. Route 53 Resolver requires network connectivity between the VPC and on-premises network. This is typically achieved via AWS Site-to-Site VPN or AWS Direct Connect. Without such connectivity, DNS queries cannot be forwarded because the endpoint ENIs need a route to the on-premises DNS servers.
Create an inbound endpoint in the VPC associated with the private hosted zone. Then configure your on-premises DNS servers to forward queries for the domain (e.g., 'aws.internal') to the inbound endpoint's IP addresses. The inbound endpoint will forward queries to the VPC resolver, which resolves the private hosted zone records.
The VPC resolver will return a DNS failure (SERVFAIL) to the requesting instance. There is no automatic fallback to other DNS servers. The query is not retried. This is why it's critical to have redundant on-premises DNS servers and healthy network connectivity.
Yes, you can share forwarding rules across accounts using AWS Resource Access Manager (RAM). However, endpoints themselves are not shareable; each account must create its own endpoints. The shared rule can be associated with VPCs in other accounts.
Enable DNS query logging to CloudWatch Logs. Check the logs for forwarded queries and responses. Verify security group rules allow port 53 traffic. Ensure the endpoint ENIs have routes to the on-premises network. Test with 'dig' or 'nslookup' from an EC2 instance using the VPC resolver IP. Also check that forwarding rules are associated with the correct VPC.
The default TTL is 60 seconds. However, Route 53 Resolver respects the TTL set by the authoritative DNS server. You can override the TTL in a forwarding rule (if the rule is for outbound forwarding) by specifying a custom TTL value between 0 and 86400 seconds.
You've just covered Route 53 Resolver for Hybrid DNS — now see how well it sticks with free SOA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?