Why Do DNS64 Answers Change Once the VPN Connects?

DNS64 answers describe a network arrangement rather than a property of the server. The resolver synthesizes an IPv6 address from an IPv4 one, and the result works only where a translator sits at the end of that prefix. Bring a VPN into the path and that arrangement can hold, change, or stop being true depending on three conditions.

Those conditions are the resolver that answered, the route your device has to the synthesized prefix, and whether anything on that route performs the translation. Each is observable, which is what makes the failure diagnosable.

What a Synthesized AAAA Record Actually Points At

A DNS64 resolver answers an AAAA query for an IPv4-only name by embedding the IPv4 address inside a prefix it has been configured to use, and the well-known prefix for that job is 64:ff9b::/96 as described in RFC 6147. The record looks like any other AAAA record to the application, which is the point: an IPv6-only client can attempt a connection without knowing the destination never had IPv6. That connection then depends on a NAT64 function translating between the two families somewhere along the path. Without that translator, the synthesized address is a plausible-looking destination that goes nowhere.

The record therefore encodes two things at once, the original IPv4 address and the assumption that a translator is reachable. Only the first is visible in the answer itself.

Three Conditions Decide Whether It Still Works

The first condition is which resolver produced the record, since one without DNS64 configured returns nothing for that name and the application fails in a different way. The second is whether your device has a route to the synthesized prefix, because an answer can be valid while the path to it is missing. The third is whether the translator owning that prefix is on the path you would use, since a tunnel carrying 64:ff9b::/96 elsewhere reaches a different function or nothing at all. All three can hold before the tunnel and fail after it, which is why the symptom looks like a sudden regression.

Check them in that order. A missing answer and a missing route look identical in a browser and completely different in a resolver log.

When the Resolver Changes, the Answer Changes

A VPN client commonly pushes its own resolver or takes over the query path entirely, and that resolver may not synthesize anything. Queries for IPv4-only names then return no AAAA record, which an IPv6-only client experiences as a name it cannot reach. The reverse also happens: a resolver that does synthesize can hand you a prefix your tunneled path does not carry.

Caching makes this harder to see. A synthesized record obtained on the office network can outlive the context that produced it, so the client keeps connecting to an address whose translator is no longer reachable. Look at the resolver answering now rather than the one that answered when the entry was stored. Flushing the cache without recording the old and new answers destroys the evidence you need.

Test the Lookup and the Path Separately

Query the name directly before involving the application, and note which server replied. The commands below show the AAAA record, the resolver in use, and whether a route to the synthesized prefix exists. Run them with the tunnel down and again with it up.

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

Read the results as a chain. A missing AAAA record means the resolver in front of you does not synthesize, so an IPv6-only path will not work for that name whatever the client does. A record present with no route means the prefix is not carried by the current path, which is a routing decision rather than a resolver fault. A route present while the request still fails points at the translator itself, and that belongs to yet another owner.

Record the resolver, the network context and the address family beside each result. That note is what lets the next comparison separate a resolver change from a routing change.