Geographic DNS and Anycast: Checking the VPN Entry You Get

A nearby DNS answer feels like a solved problem until the connection lands somewhere else. Geographic DNS and anycast both try to shorten the path, and they make that decision from different information. Neither guarantees that the gateway you reach is reachable, that it presents the identity your client expects, or that your session survives a change of node. The checks below separate those four questions.

Check whose location the resolver actually reports

An authoritative server answering a topology-sensitive query normally sees the address of the recursive resolver that asked, not the address of the person who typed the name. A centralised resolver can sit far from the clients it serves, and the answer reflects the resolver rather than them. That is not a defect; it is how the protocol behaves unless extra information is supplied. The EDNS Client Subnet specification describes both the limitation and the optional remedy.

EDNS Client Subnet can carry origin-network information when every participant supports and enables it. It is optional, it has privacy and caching consequences, and it is not permission to assume that any public resolver reports a precise user location. Ask the resolver operators before designing around it.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Check what anycast routing decided

With anycast, several locations advertise reachability for one service address, and the network delivers each client to whichever node its routing prefers. That choice is made by BGP and the surrounding policy rather than by distance on a map. Topological nearness does not generally equal better round-trip performance either, because the path that looks short can be congested or asymmetric. The address you were given tells you nothing about which node answered.

Confirm the serving location from the service side, or from a response that names it, rather than from the DNS answer alone. traceroute -n 198.51.100.20 shows the path you took and still does not name the host at the end of it, so read it as a path rather than as an answer.

Check that the session survives a node change

A DNS query is short and a VPN session is long, and the two have completely different state requirements. Routing can shift mid-session, and when it does, later packets may arrive at a node that has never seen your tunnel. Whether that is survivable depends on the implementation: shared state, a deliberate reconnect, or a documented failure. The address alone supplies none of those.

Observe the shift instead of assuming it. sudo tcpdump -ni any -c 20 esp shows the outer packets as the path changes, and a sudden change in the peer address is the shift happening. Define the intended behaviour explicitly for the implementation you run, then test it by forcing a path change. If the design assumes session replication, name the mechanism and name the failure it does not cover.

Check that the identity still matches

Every entry point has to present the identity your client profile expects. A certificate issued for the service name works across nodes, while per-node certificates force the client to accept something new, and that is where users learn to click through warnings. Keep the expected identity and the profile consistent with the entry model.

Check it from a client that reached an unusual node, because that is the case where a per-node certificate becomes visible. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com prints the chain and the names, which is exactly what the client compares. Then decide whether the profile should be narrowed or the certificate model changed.

Check the record, not just the first answer

Evaluate three scenarios and write four facts for each: normal entry, one location unavailable, and the agreed recovery case. The four facts are the resolver used, the address returned, the location that served it, and a fresh application result. That record separates a DNS selection problem from a gateway problem, a routing problem or a session-state problem. Without it, all four look identical from the client.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Run the scenarios from representative access networks rather than only from the office, because the entire question is about which entry point different clients actually reach. One network is a sample of one.