Once the tunnel is up, the last step is usually a name that works instead of an address you paste into a bookmark. A dnsmasq host record plus a resolver address the client can reach does that with two files and no multicast. The decision that actually needs thought is narrower: does the client send all DNS through the home resolver, or only the names under home.arpa? Everything below assumes an approved WireGuard setup with a Linux client and a lab resolver the home administrator already manages.

Three ways to hand the client a resolver

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

For a laptop that joins the tunnel occasionally, split-DNS is the better default: it keeps ordinary internet names on the resolver the machine already trusts. For a machine that exists to reach home services, pushing the resolver is simpler and the scope cost does not matter.

Publish the record at the resolver that owns the zone

Keep the roles apart before writing configuration: the VPN client address, the resolver, and the service are three different hosts with three different jobs. In this lab they are 10.77.0.2 for the client, 192.168.50.53 for dnsmasq and 192.168.50.20 for the NAS, with the tunnel routing the home LAN.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

The host-record line supplies the address and the local= line keeps unknown home.arpa questions inside this resolver instead of forwarding them upstream. Read your existing configuration first and reconcile anything that already defines a server, an interface or the same local domain; stacking a fragment on top of a conflicting one produces a resolver that loads happily and answers wrongly. The dnsmasq manual defines both directives and the listening controls.

Then verify the running service, not the file. A configuration test plus a restart is the minimum, and the effective answer is what a query returns.

Route the resolver, not just the web page

WireGuard's AllowedIPs decides which destinations enter the tunnel. If the resolver address falls outside it, the query leaves through the normal route and never reaches dnsmasq, even though the NAS itself is reachable. Include the resolver's address, or the LAN prefix that contains it, and check the gateway's forwarding policy on the far side.

Permit UDP and TCP on port 53 from the authorized tunnel range, with a return path back to the client's tunnel address. Do not forward port 53 from the WAN to make testing easier: an open recursive resolver on a home connection is found within hours. Binding to an interface is not an access policy on its own.

Check the answer before the application

Query the resolver directly first, then ask the system, then ask the application. Each step isolates one link in the chain, and the difference between them is the diagnosis.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

The TCP query is worth running because a truncated UDP answer forces a retry, and a policy that drops TCP 53 produces failures that look intermittent. The getent step shows what the machine's resolver configuration actually does, which is not always what you pushed.

Decide what happens when the tunnel is down

If the client's general DNS points at 192.168.50.53, every name resolution stops working when the tunnel is not up. That is acceptable on a machine that is only useful with the tunnel, and unacceptable on a laptop that also uses coffee shop Wi-Fi. Split-DNS avoids the question entirely, because only home.arpa lookups depend on the home resolver.

Remember what the name is: home.arpa is reserved for residential networks and is not globally unique, so a different network can legitimately use the same name. It is a local convenience, not a trustworthy identifier. Keep the record current when the service moves, and remove the resolver policy when the lab is retired rather than leaving a laptop pointing at an address it can only reach through a tunnel that no longer exists.

Makomi ya ndenge moko