Scenario

Suppose you have a mesh VPN of >10 nodes using your favorite solution (be it manual wireguard, innernet, tailscale or sending pigeons with ciphertext). Suppose one of these nodes is your workstation and one is an application server on your LAN. Suppose you connect to this mesh network from your workstation or from mobile and tablet devices while on the go.

Now suppose you want to run a DNS server on your mesh network to map machines to human-readable hostnames and, while you're at it, to filter ads and third-party telemetry.

Suppose, too, that you like performance and optimization and the 18ms round trip to your off-premises mesh coordination server offends you on a personal level.

Question

You know that you can deploy DNS resolvers on all your nodes (or on all the nodes you care about and will connect to) and replicate zone data across them with AXFR/IXFR. But how do you tell your clients to pick the best (lowest latency) DNS server at run-time?

Solutions (or not)

Your mesh control server can advertise one or more DNS servers to all connected clients. This is how you'd normally do this. But you don't want to do things normally. You want lightspeed DNS response thank you very much, and 18ms is not fast enough to make the Kessel Run in 24 parsecs, let alone 12.

You can host a DNS server on your LAN application server. Sure, this gives you fast response from your workstation, but what about your phone, tablet or other nodes on your mesh? If you're in the office you certainly don't want to be pinging back into your LAN to pick up DNS responses before venturing out into the internet. You'd want to go through an off-premises server in the same city. But, while you're at home on the shitter with your phone, you equally don't want to be pinging some cloud server with 18ms latency while downloading some brownware. So it's not like you can define an off-prem DNS server for all clients and override this for your workstation.

You know that the way this is achieved in The Real World™ is with Anycast IP addresses. But you also know that Anycast won't work on a LAN and certainly not with whatever routing your mesh control server uses.

Now you might be forgiven for momentarily thinking of DNS-over-HTTPS and having the DoH hostname resolve to whatever would be the most convenient IP address based on the context before remembering that DoH is slower than DNS-over-UDP because of the TLS handshake and the necessity to have something to do the resolving in the first place.

So, you're back to thinking....

A clunky, hacky, stupid solution

One way to do this would be to combine multiple methods:

• No mesh-wide DNS. Nodes are hardcoded to use the closest regional DNS resolver.
• For the workstation, this means connecting to the LAN apps server.
• For mobile clients, you can run two nearly-identical mesh contexts, one that points to the LAN DNS resolver and one that advertises a DNS resolver on the mesh control server. Then use the mobile OS scripting features to automatically switch VPN contexts when they change network connections.

This works. But there has to be a more elegant weapon for this more civilized age. Any suggestions?

* ^{DNS is all well and good, but it is not the only service that could benefit from having lower latency on demand}.