Skip to content

AWS Updated 2026-07-04

VPC DNS resolution failures: Route 53 Resolver, enableDnsHostnames, and hybrid DNS

DNS inside a VPC fails for a short list of reasons: VPC attributes turned off, private hosted zones not associated, resolver endpoints missing for hybrid, or the per-ENI query limit. Here is the diagnostic path.

DNS inside a VPC is handled by the Route 53 Resolver at the VPC base address plus two (a 10.0.0.0/16 VPC resolves against 10.0.0.2), and when it misbehaves the cause is nearly always one of five things: the enableDnsSupport or enableDnsHostnames VPC attributes are off, a private hosted zone is not associated with the VPC doing the querying, hybrid queries have no resolver endpoint to travel through, a resolver rule forwards a domain somewhere unexpected, or an instance is hitting the 1,024 packets-per-second DNS limit per ENI. The fix starts with knowing which of those layers is failing.

What’s happening

Every VPC gets the Amazon-provided resolver for free — reachable at the VPC CIDR base +2 and at 169.254.169.253 from any instance. Two VPC attributes gate its behaviour. enableDnsSupport turns resolution on at all; with it off, queries to the +2 address simply fail. enableDnsHostnames controls whether instances get DNS names and — critically — is required together with enableDnsSupport for private DNS on interface endpoints to work: with it off, sqs.ca-central-1.amazonaws.com keeps resolving to public IPs even though you paid for an endpoint.

Private hosted zones add the next layer: a zone answers queries only from VPCs it is explicitly associated with. Association is per-VPC, and it does not cross VPC peering — each VPC asks its own +2 resolver, so a private zone associated with VPC A is invisible from peered VPC B until you associate it with B too.

Hybrid setups add the last layer. The +2 resolver only answers from inside the VPC. On-premises servers cannot query it, and instances cannot reach on-premises DNS, unless you deploy Route 53 Resolver endpoints: an inbound endpoint gives your data centre IPs it can query for AWS-hosted names; an outbound endpoint plus resolver rules forwards chosen domains (corp.example.com) from the VPC to your on-premises DNS servers. Miss either half and one direction of hybrid resolution silently breaks.

What to check first

  • Both VPC attributes: enableDnsSupport and enableDnsHostnames. Non-default VPCs ship with enableDnsHostnames off.
  • Is the instance actually using the VPC resolver? A custom DHCP options set or a hand-edited /etc/resolv.conf may be pointing elsewhere.
  • Is the private hosted zone associated with this VPC? Not the VPC where it was created — the one where the query originates.
  • Do resolver rules cover the domain? A forwarding rule for example.com also captures subdomains unless a more specific rule exists.
  • Security groups on resolver endpoints: inbound/outbound endpoints need TCP and UDP 53 open to the relevant CIDRs.

How to verify

# VPC attributes (run both)
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsHostnames

# Private hosted zone associations
aws route53 list-hosted-zones-by-vpc \
  --vpc-id vpc-0abc123 --vpc-region ca-central-1

# Resolver rules and what they forward to
aws route53resolver list-resolver-rules \
  --query 'ResolverRules[].{Domain:DomainName,Type:RuleType,Targets:TargetIps}'

From an instance, isolate which resolver fails:

# Ask the VPC resolver directly
dig internal.example.com @169.254.169.253 +short
# Ask whatever resolv.conf points at
dig internal.example.com +short
# Hybrid: can we reach on-prem DNS at all?
dig corp.example.com @10.50.0.10 +short

If the +2 resolver answers but the default query fails, the problem is the instance’s resolver configuration, not the VPC. Console paths: VPC > Your VPCs > Actions > Edit VPC settings for the attributes, Route 53 > Resolver > Endpoints / Rules for hybrid plumbing. Resolver query logging (Route 53 > Resolver > Query logging) shows every query and which rule matched — it is the flow log of DNS. Full behaviour reference: the Route 53 documentation.

The fix

  1. Turn both VPC attributes on. aws ec2 modify-vpc-attribute --vpc-id vpc-0abc123 --enable-dns-support and again with --enable-dns-hostnames. This alone fixes most “interface endpoint private DNS not working” cases.
  2. Associate the private hosted zone with every VPC that queries it. Same account: Route 53 > Hosted zones > zone > Edit or create-vpc-association-authorization plus associate-vpc-with-hosted-zone cross-account. Remember peering does not carry DNS.
  3. Deploy resolver endpoints for hybrid, both directions. Inbound endpoint (two IPs in different AZs) for on-prem-to-AWS queries; outbound endpoint plus a forwarding rule per corporate domain for AWS-to-on-prem. Point on-premises conditional forwarders at the inbound endpoint IPs, never at the +2 address.
  4. Fix resolver rule precedence. The most specific domain wins; a stale rule forwarding example.com to a decommissioned DC server beats the public zone. Delete or retarget it, and add a more specific rule of type SYSTEM if one subdomain should resolve normally.
  5. Spread DNS load if you hit the per-ENI limit. 1,024 packets per second per ENI is a hard limit; symptoms are intermittent timeouts under load. Cache locally (systemd-resolved, dnsmasq, or NodeLocal DNSCache on Kubernetes) rather than raising retries.

When this is the wrong move

If two services in different VPCs cannot resolve each other, the answer may not be shared private zones at all — a PrivateLink endpoint publishes a service with its own DNS name and avoids zone-association sprawl; see VPC peering vs PrivateLink before building a web of associations. And do not reach for resolver endpoints when everything is inside AWS — they carry hourly per-ENI cost and only earn it when queries genuinely cross the hybrid boundary.

Common mistakes

  • Testing DNS from the VPC where the zone was created and declaring it healthy, while the failing workload sits in an unassociated VPC.
  • Pointing on-premises forwarders at the VPC +2 address, which is unreachable from outside the VPC.
  • Custom DHCP option sets left over from a migration, sending every instance to a dead DNS server.
  • Blaming Route 53 for what is an OS-level cache: resolvectl flush-caches before escalating.

Prevention

  • Bake enableDnsSupport and enableDnsHostnames into your VPC module defaults and let IaC drift detection catch changes.
  • Turn on Resolver query logging in production VPCs — the first hybrid DNS incident pays for the setup time.
  • Keep a one-page map of which private zones are associated with which VPCs, and which domains each resolver rule forwards where.
  • Monitor DNS timeout rates in application metrics; the per-ENI limit shows up there long before anyone suspects DNS.
  • Review resolver rules whenever a data centre or DNS server is decommissioned.

DNS failures in a VPC look random until you split them by layer — attributes, zone association, hybrid endpoints, rules, throttling — and test each with dig against a specific resolver. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.