VPC Peering DNS Not Resolving: Find the Name That Fails

If DNS is not resolving across an AWS VPC peering connection, first identify which DNS name is failing rather than rebuilding the peering connection. For an EC2 public IPv4 hostname, check the peering DNS-resolution options plus DNS support and DNS hostnames on both VPCs. For a Route 53 private hosted-zone name, the querying VPC must have access to that private hosted zone. The counterintuitive part is that an active VPC peering connection can carry private-IP traffic perfectly while DNS still fails, because peering connectivity and DNS namespace visibility are separate controls.

VPC peering is a network connection between two VPCs. DNS resolution is the process that turns a name such as db.internal.example.com into an address such as 10.20.4.50. Those jobs happen at different layers, so a successful connection to 10.20.4.50 does not prove that db.internal.example.com should resolve.

There is one more distinction that prevents a lot of wasted troubleshooting: the VPC peering DNS option has a specific purpose. It controls how public IPv4 DNS hostnames for resources in the peer are resolved. It does not automatically copy Route 53 private hosted zones, custom DNS records, Resolver forwarding rules, or an interface endpoint's private DNS namespace into the other VPC.

1. First find out what kind of DNS name is failing

The phrase “VPC peering DNS not resolving” sounds like one problem. In practice, it describes several different problems that happen to produce a similar symptom.

Run the DNS query from the same VPC, subnet, and preferably the same workload that is failing. Testing from your laptop or from an instance in another VPC can produce a completely different answer.

dig db.internal.example.com +short

Or:

nslookup db.internal.example.com

Do not stop at “it didn't work.” Write down the exact result.

The hostname type matters just as much as the error. Ask which of these you are trying to resolve:

• An EC2 public IPv4 DNS hostname in the peered VPC.
• A custom name stored in a Route 53 private hosted zone.
• An AWS service name that you expect to use an interface VPC endpoint.
• A hostname stored on your own DNS server.
• An on-premises hostname reached through Route 53 Resolver forwarding.

Those are not interchangeable cases.

Ethan explains it this way: “The road and the address book are different systems, Jake. If the road is open but the address book has no entry, rebuilding the road is just expensive exercise.”

2. Fix EC2 public hostname resolution over VPC peering

This is the case the VPC peering DNS setting directly addresses.

Imagine an EC2 instance in VPC B has a public IPv4 DNS hostname. An instance in VPC A uses that hostname while A and B are connected through VPC peering.

With peering DNS resolution disabled, the public IPv4 hostname resolves to its public IPv4 address. With the relevant peering DNS-resolution option enabled, the hostname can resolve to the instance's private IPv4 address when queried from the peer.

The peering connection must already be in the active state. This option is not something you turn on while creating a new peering request.

Console route

1. Open the Amazon VPC console.
2. Choose Peering connections.
3. Select the correct peering connection.
4. Confirm its status is Active.
5. Choose Actions.
6. Choose Edit DNS settings.
7. Enable the requester or accepter DNS-resolution option required for the direction in which names must resolve.
8. If workloads on both sides need to resolve peer hostnames, configure both sides.
9. Save the changes.

Pay attention to requester and accepter. They are not decorative labels. The owner of the requester VPC controls requester-side peering options, and the owner of the accepter VPC controls accepter-side options.

If both VPCs belong to the same account, you can manage both sides. If they belong to different accounts, the administrator of one account might not have permission to modify the other side.

CLI route

Start by describing the connection. Do not assume which VPC is requester and which is accepter based on which application you are looking at today.

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0123456789abcdef0

Enable the requester-side option:

aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --requester-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

Enable the accepter-side option when required:

aws ec2 modify-vpc-peering-connection-options \
  --vpc-peering-connection-id pcx-0123456789abcdef0 \
  --accepter-peering-connection-options AllowDnsResolutionFromRemoteVpc=true

The name AllowDnsResolutionFromRemoteVpc is easy to read too quickly. Look at the returned requester and accepter options instead of assuming that one successful CLI command configured both directions.

3. Check enableDnsSupport and enableDnsHostnames on both VPCs

If the peering DNS option looks correct but the result is still wrong, check the DNS attributes on the VPCs themselves.

enableDnsSupport controls whether DNS resolution through the Amazon-provided DNS capability is supported for the VPC. enableDnsHostnames controls DNS-hostname behavior. The standard VPC peering DNS-resolution setup requires both VPCs to have DNS hostnames and DNS resolution enabled.

That “both VPCs” detail matters. The server lives in VPC B, so people naturally spend twenty minutes inspecting VPC B and forget VPC A, where the query actually begins.

Console route

1. Open the VPC console.
2. Choose Your VPCs.
3. Select VPC A.
4. Choose Actions → Edit VPC settings.
5. Confirm DNS resolution and DNS hostnames are enabled.
6. Repeat the same check for VPC B.

CLI route

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --attribute enableDnsSupport

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --attribute enableDnsHostnames

If either must be enabled:

aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --enable-dns-support '{"Value":true}'

aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --enable-dns-hostnames '{"Value":true}'

4. Private hosted-zone names need private hosted-zone access

This is where people often enable VPC peering DNS resolution, see no improvement, and assume the feature is broken.

Suppose VPC B is associated with a Route 53 private hosted zone named:

internal.example.com

The zone contains:

db.internal.example.com  A  10.20.4.50

Now VPC A is peered with VPC B.

That peering connection does not automatically associate VPC A with internal.example.com. If workloads in VPC A must resolve records from the private hosted zone, VPC A needs access to that private DNS namespace.

For a straightforward same-account design, associate VPC A with the private hosted zone.

Console route for VPCs in the same account

1. Open Route 53.
2. Choose Hosted zones.
3. Select the private hosted zone.
4. Choose Edit.
5. Choose Add VPC.
6. Select the VPC Region and the VPC ID that needs to resolve the zone.
7. Save the change.

CLI route

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0123456789abcdef0

Two things must already exist: the private hosted zone and the VPC. This operation associates them; it does not convert a public hosted zone into a private hosted zone.

Then test again from the source VPC:

dig db.internal.example.com +short

If the answer is now 10.20.4.50 but the connection to the database still fails, DNS is no longer your first suspect.

5. The NXDOMAIN trap: a matching private zone can block public fallback

This is one of the most useful edge cases to know when the VPC association looks correct.

VPC Resolver chooses the most specific private hosted zone whose name matches the requested domain. It then looks for the requested record and record type inside that private zone.

If a matching private hosted zone exists but the requested record does not exist there, Resolver does not simply continue to public DNS and give you a public answer. It can return NXDOMAIN.

Example:

• Your VPC is associated with a private hosted zone named example.com.
• Public DNS also contains shop.example.com.
• The private example.com zone does not contain shop.example.com.
• A workload in the associated VPC requests shop.example.com.

Seeing the public record in an internet DNS tool does not prove your VPC should receive that public result. The private namespace has already matched the query.

Check what actually exists in the private zone:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z123456789EXAMPLE

Also verify the record type. Having an A record does not mean every AAAA or other query has a matching answer.

This also explains the frustrating sentence, “It resolves on my laptop but not on EC2.” Your laptop may be using public DNS while the EC2 instance is inside a VPC associated with a matching private namespace.

6. Check overlapping private zones and Resolver rules

A second “everything looks right” failure appears when more than one DNS mechanism can match the same namespace.

Private hosted zones can overlap. You might have a private zone for:

example.com

and another for:

dev.example.com

A query for api.dev.example.com matches the more specific namespace.

Resolver rules add another layer. If a Resolver forwarding rule matches a domain, that forwarding rule can take precedence over a private hosted zone for the same namespace. That means a query you expected Route 53 to answer locally might instead be forwarded to another DNS server.

This is why “the record definitely exists in Route 53” is not the end of the investigation.

Inspect Resolver rules associated with the VPC:

aws route53resolver list-resolver-rule-associations \
  --filters Name=VPCId,Values=vpc-0123456789abcdef0

Then list the rules themselves if you find a relevant association:

aws route53resolver list-resolver-rules

Look for a rule whose domain matches or is a parent of the failing name.

Ethan's advice here is simple: “When two DNS systems both claim the same neighborhood, stop staring at the record and ask which system gets the query first.”

7. Cross-account private hosted zones need authorization first

If the private hosted zone belongs to Account A and the VPC belongs to Account B, you cannot treat the association like an ordinary same-account console task.

The hosted-zone owner first authorizes the specific VPC association. Then the VPC-owning account performs the association.

Step 1: Account A authorizes Account B's VPC

aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0123456789abcdef0

Step 2: Account B associates its VPC

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0123456789abcdef0

After the association succeeds, the authorization can be deleted. Removing the authorization does not remove the completed hosted-zone association.

If you have ten VPCs in another account, do not assume one blanket authorization covers all of them. Each VPC association is its own operation.

Also check the AWS partition. The hosted zone and VPC must belong to the same partition. A normal commercial AWS VPC, an AWS GovCloud (US) VPC, and an AWS China VPC are not interchangeable association targets.

There is another modern inspection trap: some Route 53 associations can be created through newer Route 53 mechanisms such as Profiles. Do not assume that one legacy association-listing call always gives you the entire DNS picture. If your organization uses Route 53 Profiles, include those resource associations in the investigation.

8. Interface VPC endpoint private DNS does not automatically extend across peering

Now consider a different hostname:

ssm.us-east-1.amazonaws.com

VPC A contains an interface VPC endpoint for that service and private DNS is enabled on the endpoint.

Inside VPC A, the ordinary service name can resolve to the private IP addresses of the endpoint network interfaces because enabling private DNS creates AWS-managed private DNS behavior for that endpoint.

Then someone peers VPC B with VPC A and expects VPC B to inherit the same private answer.

That is the mistake.

The endpoint's private DNS behavior is tied to the VPC where that endpoint DNS configuration applies. VPC peering does not automatically make the endpoint's hidden private namespace available to the peer.

When a centralized endpoint design requires VPC B to resolve the normal service name to an endpoint in VPC A, the DNS architecture must be designed explicitly.

One pattern is:

1. Create the interface endpoint for the target service with its automatic private DNS behavior disabled when that is required by the centralized design.
2. Create a Route 53 private hosted zone for the service namespace.
3. Create the appropriate record or alias that points to the endpoint's Regional DNS target or endpoint addresses, depending on the design.
4. Associate that private hosted zone with each VPC that should receive the private endpoint answer.
5. Make sure the endpoint security group permits the intended client traffic.
6. Make sure VPC peering routes allow the clients to reach the endpoint network interfaces.

Do not blindly copy that pattern into production just because the name currently resolves publicly. First map who already uses the service name. Changing private DNS for a broad AWS service namespace can redirect many workloads at once.

9. Custom DNS can bypass the Route 53 answer you expected

If your VPC uses Windows DNS, Active Directory DNS, BIND, Infoblox, or another custom resolver, do not assume your EC2 instance is sending queries directly to VPC Resolver.

Check which DNS server the workload is actually using.

On Linux, start with:

cat /etc/resolv.conf

On systems using systemd-resolved, also inspect:

resolvectl status

On Windows:

ipconfig /all

Now ask the key question: does that DNS server know how to resolve the private zone?

A custom DNS server does not learn Route 53 private hosted-zone records merely because its VPC is peered to another VPC. The custom server must either host the relevant data itself or forward the relevant private queries into the appropriate AWS DNS path.

For a VPC whose primary IPv4 CIDR is 10.20.0.0/16, the VPC DNS address represented by the base network plus two is 10.20.0.2. VPC Resolver is also available through the link-local address 169.254.169.253.

If your custom resolver is supposed to forward internal.example.com, inspect the conditional forwarding configuration there instead of repeatedly modifying the peering connection.

10. On-premises names need Resolver forwarding, not just VPC peering

Suppose VPC A is peered with VPC B, and VPC B also has connectivity toward an on-premises network where corp.example.com is hosted.

Do not assume this chain works:

VPC A -> VPC peering -> VPC B -> VPN/Direct Connect -> on-prem DNS

VPC peering does not provide general edge-to-edge or transitive routing through a peer's VPN, Direct Connect connection, internet gateway, NAT device, or gateway endpoint.

So a design that expects VPC A simply to “borrow” VPC B's private connection to the corporate network can fail even though A and B are correctly peered.

For hybrid DNS, Route 53 Resolver inbound and outbound endpoints and Resolver rules exist specifically to build controlled DNS paths between VPCs and external DNS infrastructure.

An outbound Resolver endpoint sends matching DNS queries from AWS toward designated DNS servers. An inbound Resolver endpoint allows DNS resolvers outside the VPC to send appropriate queries into the Route 53 Resolver environment.

The important part for this article is not to add endpoints automatically. It is to recognize when your problem has stopped being “DNS between two peered VPCs” and has become “hybrid DNS forwarding between AWS and another network.”

11. If DNS returns the right IP, stop changing DNS

This sounds obvious until you are an hour into an outage and every browser tab contains the word DNS.

Suppose:

$ dig db.internal.example.com +short
10.20.4.50

If 10.20.4.50 is the address you intended, DNS has delivered an answer.

Now test the application port instead of editing hosted zones.

For a TCP service on Linux:

nc -vz 10.20.4.50 5432

Or test the name itself:

nc -vz db.internal.example.com 5432

If DNS resolves correctly but the TCP connection times out, inspect:

• The route table associated with the source subnet.
• The route table associated with the destination subnet where relevant.
• Routes pointing the peer CIDR toward the correct peering connection.
• The destination security group.
• The source security controls required by your design.
• Network ACL rules.
• Whether the application is actually listening on the expected address and port.

Do not inspect only the VPC's main route table. A subnet can be associated with a different route table.

Also remember that VPC peering is not transitive. VPC A cannot use VPC B as a router to reach VPC C merely because B happens to be peered with both.

Reachability Analyzer is useful once you know the destination address and want help identifying whether supported AWS network configuration blocks the path.

12. Cross-Region peering works, but configure each side deliberately

DNS resolution support is available for inter-Region VPC peering, but cross-Region peering adds one practical source of mistakes: administrators run the right command in the wrong Region.

If requester VPC A is in us-east-1 and accepter VPC B is in us-west-2, inspect the connection from the proper regional context and modify the requester and accepter options with the correct ownership and Region in mind.

The same principle applies to private hosted-zone association commands: when you specify a VPC for the association, give the VPC's actual Region.

Do not diagnose a cross-Region DNS issue based on the fact that “the checkbox is enabled in the console” without confirming which side and which connection you are viewing.

Shared VPCs introduce another ownership detail. Participants in shared subnets are not the VPC owner. Peering operations belong to the VPC owner. If you cannot see or modify an expected peering control, first establish whether your account actually owns the VPC.

13. A stale DNS cache can make a fixed configuration look broken

DNS answers can be cached by operating systems, local stub resolvers, application runtimes, proxies, and DNS servers.

That means this sequence is possible:

1. The application queries a hostname while the private hosted-zone association is wrong.
2. The resolver returns a negative or undesired answer.
3. You correct the AWS configuration.
4. The application continues using a cached answer for some period.
5. You conclude that the AWS change had no effect.

Do not respond by deleting and recreating the peering connection.

Compare a fresh lookup with what the application is doing. On systems with a local resolver, inspect that resolver's cache behavior. If an application maintains its own DNS cache, restarting only the command-line resolver does not force that application to forget an old address.

Likewise, changing a DNS record and immediately testing from one long-running Java process can tell you more about that process's caching behavior than about Route 53.

This is also why recording the TTL and the exact time of a DNS change is useful during production troubleshooting.

Jake's shop analogy returns here: his employee updated the supplier's phone number, but Jake kept pressing “redial.” The address book was fixed; the phone was still using yesterday's call history.

14. Worked example: peering works, database name does not

Use this example as a model for separating DNS from connectivity.

There is an active VPC peering connection. The source subnet has a route for 10.20.0.0/16 through the peering connection. The destination side has the return path it needs.

From VPC A:

nc -vz 10.20.4.50 5432

succeeds.

But:

dig db.internal.example.com +short

does not return 10.20.4.50.

That combination is your clue. Stop editing route tables. The working private-IP test already told you the peering network path can reach the database.

Next, inspect the private hosted-zone associations.

aws route53 get-hosted-zone \
  --id Z123456789EXAMPLE

If VPC A does not have access to that private namespace, associate it.

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123456789EXAMPLE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0aaaaaaaaaaaaaaaa

Then query again from VPC A:

$ dig db.internal.example.com +short
10.20.4.50

You have now proved something useful without claiming magic: the source receives the intended DNS answer, and the destination private IP was already reachable.

The expensive wrong fix

A team sees “private DNS not resolving” and jumps directly to Route 53 Resolver endpoints.

Resolver endpoints are useful when you genuinely need DNS queries to cross between a VPC and another DNS environment. They are not required merely to associate another VPC with a private hosted zone.

Using the US East (N. Virginia) Resolver endpoint price of $0.125 per endpoint IP address per hour, and the requirement to use at least two IP addresses for an endpoint, the endpoint-hour arithmetic for a 730-hour month is:

2 endpoint IPs × $0.125/hour × 730 hours
= $182.50 per month

That is before DNS query charges that apply to traffic through Resolver endpoints. The first one billion such queries per month are priced at $0.40 per million queries in US East (N. Virginia). Prices checked October 3, 2026.

If the actual problem was one missing private hosted-zone association, that $182.50 monthly endpoint footprint does not make the original mistake more correct. It just makes it more expensive.

15. What changed recently in Route 53 Resolver

The standard VPC peering DNS controls discussed above still apply. The recent Resolver changes are important mainly if your troubleshooting path reaches hybrid DNS rather than ordinary peer hostname resolution.

If your architecture uses private-zone delegation, inbound/outbound Resolver endpoints, or IPv6-only clients, old advice that assumes only conditional forwarding or IPv4 query paths can now be incomplete.

If your problem is simply that VPC A cannot resolve a Route 53 private name hosted for VPC B, do not let those newer features distract you from the basic association check.

16. The five-minute VPC peering DNS diagnostic

1. Run the exact DNS lookup from the failing workload. Save the answer.
2. Try the destination private IP directly. If that fails, investigate network reachability as well as DNS.
3. Classify the hostname. EC2 public hostname, Route 53 private record, interface endpoint service name, custom DNS record, or on-premises name.
4. If it is an EC2 public hostname, inspect the VPC peering DNS-resolution options.
5. Check enableDnsSupport and enableDnsHostnames on both VPCs.
6. If it is a private hosted-zone record, verify the querying VPC's association.
7. Verify the exact record exists. A matching private zone without the matching record can produce NXDOMAIN rather than the public answer you expected.
8. Check for overlapping namespaces or Resolver rules.
9. If custom DNS is configured, identify which server actually received the query.
10. If an interface endpoint is involved, inspect the endpoint's private DNS scope.
11. If the correct private IP is returned, stop changing DNS. Move to routing, security groups, network ACLs, and the application listener.

Notice what is missing from that list: delete the peering connection and recreate everything.

That is intentionally not step one.

17. CLI checklist for a real incident

You do not need to run every command below. Use the ones that match the hostname type you identified.

Check the peering connection

aws ec2 describe-vpc-peering-connections \
  --vpc-peering-connection-ids pcx-0123456789abcdef0

Confirm the status and note the requester/accepter VPC IDs.

Check VPC DNS resolution

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --attribute enableDnsSupport

Check VPC DNS hostnames

aws ec2 describe-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --attribute enableDnsHostnames

Check a private hosted zone

aws route53 get-hosted-zone \
  --id Z123456789EXAMPLE

List hosted zones associated with a VPC

aws route53 list-hosted-zones-by-vpc \
  --vpc-id vpc-0123456789abcdef0 \
  --vpc-region us-east-1

If your organization uses Route 53 Profiles, include Profile resource associations in your inventory rather than assuming this one command is the full list of every way DNS resources can be associated.

Check records inside the private zone

aws route53 list-resource-record-sets \
  --hosted-zone-id Z123456789EXAMPLE

Check Resolver rule associations

aws route53resolver list-resolver-rule-associations \
  --filters Name=VPCId,Values=vpc-0123456789abcdef0

Inspect routes instead of guessing

aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0

Do this after the DNS lookup gives you a destination address or when the direct private-IP test also fails.

18. Symptom-to-fix table

19. When nothing works, collect this before opening a support case

If you have changed the obvious setting twice and the answer still makes no sense, stop toggling things. Build a small evidence packet.

Capture:

• The exact failing fully qualified domain name.
• The record type being requested: A, AAAA, CNAME, or something else.
• The exact dig or nslookup output.
• The source VPC ID.
• The source subnet ID.
• The destination VPC ID.
• The peering connection ID.
• The requester and accepter VPC IDs.
• The Region of each VPC.
• The result of a direct private-IP connectivity test.
• enableDnsSupport for both VPCs.
• enableDnsHostnames for both VPCs.
• The peering DNS-resolution options.
• The private hosted-zone ID if applicable.
• The VPC associations for that private zone.
• The exact record that should answer the query.
• Any Route 53 Resolver rules associated with the source VPC.
• The DNS servers configured by the instance or container.
• The relevant route table rather than only the main route table.
• The endpoint ID if an interface VPC endpoint is involved.

A compact incident note might look like this:

Source VPC: vpc-AAAA
Source subnet: subnet-1111
Destination VPC: vpc-BBBB
Peering: pcx-CCCC
Peering state: active

Hostname:
db.internal.example.com

Query:
dig db.internal.example.com A

Expected:
10.20.4.50

Actual:
NXDOMAIN

Direct TCP to 10.20.4.50:5432:
works

Source DNS:
Amazon-provided DNS

Private hosted zone:
Z123456789EXAMPLE

Current zone association:
vpc-BBBB only

That is much more useful than “VPC DNS broken.” It identifies exactly where the contradiction is.

And if the evidence already says the private-IP connection works while the private zone is only associated with VPC B, you may not need a support case at all. You have a specific configuration mismatch to fix.

20. AWS VPC peering DNS FAQ

Why is DNS not resolving across my AWS VPC peering connection?

First identify the hostname type. For an EC2 public IPv4 hostname, check the peering DNS-resolution options plus DNS hostnames and DNS resolution on both VPCs. For a Route 53 private hosted-zone name, make sure the VPC issuing the query has access to that private hosted zone and that the exact record exists. For interface endpoint or custom DNS names, inspect their separate DNS architecture.

How do I enable DNS resolution for a VPC peering connection?

In the VPC console, open Peering connections, select the active peering connection, choose Actions, and choose Edit DNS settings. Enable the requester or accepter DNS-resolution option needed for your traffic direction. With the CLI, use modify-vpc-peering-connection-options and set AllowDnsResolutionFromRemoteVpc=true on the appropriate side.

Why does VPC peering work by private IP but not by hostname?

Routing and DNS are separate. Working private-IP traffic proves that at least one network path is usable. The hostname can still fail because the source VPC cannot see the required private hosted zone, is using a different DNS server, has the wrong peering DNS option, or receives an answer from another DNS namespace.

Does VPC peering automatically share Route 53 private hosted zones?

No. Peering gives the VPCs network connectivity. A Route 53 private hosted zone has its own associations. If VPC B is associated with internal.example.com, peering VPC A with VPC B does not automatically make that private hosted zone available to VPC A.

Why does my EC2 public DNS hostname resolve to a public IP from the peer VPC?

Check whether the required VPC peering DNS-resolution option is enabled. When the feature is disabled, the public IPv4 DNS hostname resolves to the public IPv4 address. When the required peering DNS setting is enabled and the other DNS requirements are satisfied, the peer can resolve that public hostname to the instance's private IPv4 address.

Do both VPCs need enableDnsSupport and enableDnsHostnames?

For VPC peering DNS resolution, check both VPCs. The peering DNS feature requires DNS hostnames and DNS resolution to be enabled on both sides. Do not inspect only the VPC that contains the destination instance.

Why does a Route 53 private hostname return NXDOMAIN even though a public record exists?

If VPC Resolver finds a matching private hosted zone, it searches that private namespace for the requested record. If the private zone matches but the requested record and type are missing, the query can return NXDOMAIN instead of falling through to the public DNS record. Check the private zone and the exact record type.

How do I associate a Route 53 private hosted zone with a VPC in another AWS account?

The account that owns the private hosted zone first creates a VPC association authorization for the specific VPC. The account that owns the VPC then associates that VPC with the hosted zone. The cross-account workflow is programmatic rather than a simple same-account console association.

Does VPC peering DNS work between different AWS Regions?

Yes. DNS resolution support works with inter-Region VPC peering. Configure the required requester and accepter peering options deliberately, and make sure you are operating in the appropriate Region for each side when using regional CLI operations.

Why does an interface VPC endpoint resolve privately in one VPC but publicly in the peered VPC?

Enabling private DNS on an interface endpoint provides private DNS behavior in the VPC where that endpoint configuration applies. A peered VPC does not automatically inherit that private namespace. Centralized endpoint designs need an explicit DNS architecture, commonly involving a private hosted zone associated with each client VPC.

Can I directly use the Amazon DNS server in the peer VPC?

No. A VPC peering connection does not turn the Amazon DNS server in one VPC into a DNS server that the peer can directly query as though it were an ordinary host. Configure DNS from the querying VPC using the appropriate peering DNS option, private hosted-zone association, Resolver design, or custom DNS forwarding.

Can a Route 53 Resolver rule override my private hosted zone?

A matching Resolver rule can take precedence over a private hosted zone for the same namespace. If the Route 53 record exists but queries are unexpectedly reaching another DNS server, inspect Resolver rules associated with the source VPC and look for a matching or parent domain.

Why does dig work but my application still cannot connect?

If dig returns the correct private IP, DNS may already be working. Test the application port and inspect route tables, security groups, network ACLs, endpoint security, and whether the destination service is actually listening. Also consider application DNS caching if the application still uses an older address.

Why does the DNS name work on my laptop but not inside the VPC?

Your laptop and VPC workload might be using different DNS namespaces. A VPC associated with a private hosted zone can receive a private answer or NXDOMAIN where your laptop's public resolver sees a public record. Compare the DNS servers being queried and check whether a matching private hosted zone exists.

Do I need Route 53 Resolver endpoints to fix VPC peering DNS?

Not for the ordinary case where you only need an EC2 public hostname to resolve privately over peering or need another VPC associated with a Route 53 private hosted zone. Resolver endpoints are intended for DNS forwarding and hybrid DNS paths. Adding them to solve a missing hosted-zone association adds unnecessary complexity and cost.

What should I check first when VPC peering DNS suddenly stops working?

Run the failing lookup from the actual workload and record the answer. Test the destination private IP separately. Then identify whether the name comes from EC2 public DNS, a Route 53 private hosted zone, an interface endpoint, custom DNS, or an on-premises DNS server. That classification tells you which configuration owns the failure.

21. The shortest reliable way to think about this problem

When somebody says “VPC peering DNS is broken,” translate that sentence into two questions.

First: what DNS system owns this name?

An EC2 public hostname points you toward the VPC peering DNS-resolution option. A custom Route 53 private record points you toward private hosted-zone visibility. An AWS service name intended for a centralized interface endpoint points you toward endpoint DNS architecture. A corporate hostname points you toward custom DNS or Route 53 Resolver forwarding.

Second: once the name becomes an IP address, can the network reach that IP?

If the answer to the first question is wrong, fix DNS. If the first answer is right and the second is wrong, fix the network path. Mixing those two investigations is how a one-checkbox problem turns into a four-hour rebuild.

Jake's database did not need a new VPC, a new peering connection, or a pair of Resolver endpoint IPs. It needed the DNS namespace and the network path to be treated as two separate pieces.

If your hostname currently fails in one VPC but works in the other, start with one fresh dig from the failing side and write down exactly what it returns. That single answer usually tells you which branch on this page deserves your attention next.

Revision note. Written October 3, 2026. When the IP works and the name doesn't, the network is fine and the namespace is the puzzle. Follow the name, not the packet, and it resolves sooner than it feels right now.