Private DNS Works in the VPC but Not Over the VPN
A private name that resolves inside EC2 but not over the VPN is a resolver path problem. Read the failure shape before you edit the zone record.
A private name resolves from an EC2 instance but not from a laptop connected through the VPN, and the zone looks correct in the console. The instinct is to edit the record, which is almost never the problem. The record is answering someone; it is just not answering your laptop. What differs between the two callers is which resolver they ask, and whether that resolver has a supported path into the VPC's DNS view.
I start by proving the record exists, then spend the rest of the time on the query path. Those are separate systems and they fail in different shapes.
Read the failure shape before you change anything
Three outcomes mean three different things, and one query tells them apart: run dig for the name against the resolver the client is actually using.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
A timeout is a network statement. NXDOMAIN is a DNS-view statement. A public answer is a policy statement. Editing a zone record while you have a timeout throws away the one useful piece of evidence in the case.
Why the VPC's plus-two address is not a remote resolver
The CIDR-plus-two address is a local service for resources inside the VPC. AWS documents that forwarding queries from on-premises networks, or from another VPC's DNS servers, directly to that address is unsupported and can produce unstable results.
That does not mean an experiment never appears to work. It means the behavior is not a contract you can put in a helpdesk script. The supported direction is an inbound Resolver endpoint: an address pair inside your VPC, reachable from the network you control, that accepts queries arriving from outside AWS.
Build the path in the order that fails cleanly
Three hops have to exist, and each has its own failure mode.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesThe forwarder needs a route to the endpoint addresses through the VPN, and the return path has to work as well. For conventional DNS on port 53 the endpoint answers over UDP and TCP, so both protocols need to be permitted and both have to survive any stateful inspection in the middle.
Then check the DNS view separately. A private hosted zone is visible only to the VPCs it is associated with, or through a deliberate sharing arrangement. A reachable endpoint does not by itself make every private zone resolvable in its resolution context.
An outbound endpoint serves the opposite direction and will not answer a query coming in from your laptop.
Verify from both ends
Query from the client against the forwarder, then from the forwarder against the endpoint. If the client fails while the forwarder succeeds, the gap is between those two.
If both fail, look at the security policy on the endpoint and at the source address it actually sees. A forwarder behind NAT presents the NAT address rather than the laptop's VPN address, and that difference alone is enough to drop the query. If both succeed but the application still fails, the application may be using a different resolver than the one you tested.
Keep the public and private namespaces separate on purpose. Split DNS is a policy you configure, not a side effect of one lookup happening to return data.
What I would not do
I would not add a NAT rule that made a single lookup work and call it a design.
I would not point every remote client at the plus-two address because one test once returned a record. And I would not widen the endpoint's security policy to the whole VPN pool when a single forwarder needs access. If the organization already runs an approved forwarder inside the VPC, read that design first, because the second endpoint you add is the one nobody documents.