AWS 166: Route 53 Resolver and hybrid DNS
Why this lesson matters
Connect VPC and on-premises DNS with inbound and outbound endpoints, forwarding rules, private zones, query logs, DNS Firewall, and non-transitive network paths.
The VPC Route 53 Resolver answers AWS private/public names for VPC clients. Resolver endpoints do not “connect DNS automatically”: inbound and outbound directions, conditional rules, zone associations, network routes, security groups, NACLs and on-premises resolver configuration must form a deliberate bidirectional design.
What you will be able to do
By the end, you can:
- explain route 53 resolver and hybrid dns in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Connect VPC and on-premises DNS with inbound and outbound endpoints, forwarding rules, private zones, query logs, DNS Firewall, and non-transitive network paths. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 Resolver and hybrid DNS. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 Resolver and hybrid DNS. |
| Cost model | Endpoint IP-hours and queries can charge. Use supplied evidence in personal accounts unless an instructor owns the hybrid lab. |
| Safe rejection rule | Avoid assuming an endpoint creates VPN or Direct Connect connectivity or building circular forwarding rules. |
How the request flows
+----------------------+
| DNS client |
+----------------------+
|
v
+------------------------------------------------+
| Network path to inbound or outbound endpoint |
+------------------------------------------------+
|
v
+--------------------------------------------+
| Forwarding rule and authoritative server |
+--------------------------------------------+
|
v
+-------------------------------------+
| Answer, log, and failure evidence |
+-------------------------------------+For Route 53 Resolver and hybrid DNS, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 Resolver and hybrid DNS. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 Resolver and hybrid DNS. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use Resolver endpoints for controlled hybrid DNS queries over established network connectivity. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid assuming an endpoint creates VPN or Direct Connect connectivity or building circular forwarding rules. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Resolver paths
Every VPC includes the Amazon-provided resolver at the VPC-plus-two address and link-local addresses as supported. An inbound endpoint places resolver IPs in selected VPC subnets so on-premises DNS servers can forward private AWS zones to those IPs. An outbound endpoint lets VPC Resolver forward matching domains to on-premises DNS server IPs using Resolver rules. Endpoints use ENIs and should span at least two AZs; security groups must permit TCP and UDP 53 in the correct direction, and network paths through VPN/Direct Connect/TGW must be symmetric.
Forward rules match suffixes and the most specific domain wins. System rules can override forwarding behavior for AWS/private names. Sharing rules through RAM does not share the outbound endpoint itself or network reachability. Private hosted-zone association grants a VPC view of that zone; authorization is required cross-account. Route 53 Profiles can centrally associate supported Resolver/private-DNS configurations with VPCs where current features fit, but inherited/local precedence and Region scope must be documented.
DNS is not transitive through VPC peering merely because IP routing exists. The built-in resolver has rules about where queries may originate; use endpoints/rules rather than pointing arbitrary networks at the VPC resolver address. Avoid forwarding a parent zone in both directions, which creates loops. Reserve subdomains (aws.corp, onprem.corp) and define authoritative owner/delegation whenever possible.
Resolver query logging records VPC DNS queries to CloudWatch Logs/S3/Firehose with privacy and cost controls. DNS Firewall evaluates domain queries through VPC Resolver using ordered rule groups and allow/block/alert/advanced rules; it blocks names, not the resolved IP or direct HTTPS traffic. DNSSEC validation for recursive answers and authoritative DNSSEC signing are separate. Resolver endpoints charge per ENI-hour and query; logs/firewall/rules/network links add cost even when idle.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open Route 53 Resolver, Inbound endpoints, Outbound endpoints, Rules, Query logging, and DNS Firewall; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws route53resolver list-resolver-endpoints --query 'ResolverEndpoints[].{Name:Name,Direction:Direction,Status:Status,Protocols:Protocols,Id:Id}' --output table
aws route53resolver list-resolver-rules --query 'ResolverRules[].{Name:Name,Type:RuleType,Domain:DomainName,Status:Status}' --output table
aws route53resolver list-resolver-query-log-configs --output tableExpected interpretation
Endpoints and rules prove the control plane. Success also requires network connectivity, TCP and UDP 53, correct association, no forwarding loop, and an authoritative answer.
Practical work
Draw on-premises clients resolving db.corp.example in a VPC and VPC clients resolving legacy.corp. Add endpoint IPs across AZs, rules, routes, SGs, logging, failure tests, and costs.
Include query direction arrows for UDP/TCP, zone/rule specificity, DHCP option behavior, cross-account sharing/Profile ownership and expected dig answer from on-prem/VPC/public clients. Test one endpoint-AZ loss, TCP 53 blocked (large/truncated response), forwarding loop, wrong parent suffix, overlapping private zone, unreachable on-prem DNS, NXDOMAIN negative cache, DNS Firewall block/custom response and direct-IP bypass.
Diagnose this topic from its own evidence
Capture client resolver configuration and dig +tcp/UDP result, then endpoint IP/health, SG/NACL/routes, rule association and target server logs. REFUSED often means server policy; SERVFAIL can be loop/DNSSEC/upstream; timeout is path/firewall; wrong answer is rule/zone specificity/cache. Query logging absence can mean wrong VPC/log config or query bypassing Resolver. Do not add a broad . forwarding rule until AWS service/private-zone consequences are proven.
Cost and cleanup
Endpoint IP-hours and queries can charge. Use supplied evidence in personal accounts unless an instructor owns the hybrid lab.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Connect VPC and on-premises DNS with inbound and outbound endpoints, forwarding rules, private zones, query logs, DNS Firewall, and non-transitive network paths.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 Resolver and hybrid DNS.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 Resolver and hybrid DNS.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid assuming an endpoint creates VPN or Direct Connect connectivity or building circular forwarding rules.
- Which cost dimensions and retained resources need an owner?
Expected direction: Endpoint IP-hours and queries can charge. Use supplied evidence in personal accounts unless an instructor owns the hybrid lab.
Lesson acceptance
Pass when the learner traces inbound and outbound directions, deploys conceptual multi-AZ endpoint/rule/zone associations, handles TCP+UDP, prevents loops, uses logging/firewall safely and calculates endpoint idle cost. Fail if peering implies DNS transitivity, inbound/outbound are reversed, DNS Firewall is called an IP firewall, or one endpoint IP is called resilient.