Secondary Local DNS server for Wireguard

You don't need another local domain for this, you can use the same lan domain and have them resolve to hosts on another network. To illustrate how this can work, I will contrive some example networks as follows:

  • Network berry.lan with prefix fd82:272a:3c46:0100::/56
    • Router router.berry.lan with address fd82:272a:3c46:0100::1
    • Server rasp.berry.lan with address fd82:272a:3c46:0100::2
  • Network nut.lan with prefix fd82:272a:3c46:0200::/56
    • Router router.nut.lan with address fd82:272a:3c46:0200::1
    • Desktop wal.nut.lan with address fd82:272a:3c46:0200::3

The two routers have a site-to-site Wireguard tunnel correctly configured. The allowed IPs for each peer would be the network prefix for that peer. The routers also advertise their respective prefixes on their networks so the hosts within those networks get the same prefix. For example, configure router.berry.lan with /etc/config/network:

config globals 'globals'
    option ula_prefix 'fd82:272a:3c46:0100::/56'

config wireguard_vpn
    option description 'nut.lan'
    list allowed_ips 'fd82:272a:3c46:0200::/56'
    option route_allowed_ips '1'

router.nut.lan should be set up the same way.

At this point, wal.nut.lan can reach rasp.berry.lan by IP address. This will involve tunneling between the two routers. wal.nut.lan will choose the correct source address such that replies from rasp.berry.lan will reach wal.nut.lan back through the same Wireguard tunnel.

Of course, typing IPv6 addresses is a chore, so we set up DNS so we can reach these hosts by name. Fortunately, OpenWrt runs dnsmasq out-of-the-box, and it can be configured to use DNS forwarding. This allows you to resolve names in other networks through the Wireguard tunnel, not just the local network.

For example, configure router.nut.lan with /etc/config/dhcp:

config dnsmasq
    option local '/nut.lan/'
    option domain 'nut.lan'
    option localservice '0'
    list rebind_domain 'lan'
    list server '/berry.lan/fd82:272a:3c46:0100::1'

router.berry.lan should be set up the same way.

Let's see what happens when you ssh pi@rasp.berry.lan from your desktop wal.nut.lan:

  1. Desktop attempts to resolve rasp.berry.lan. Because OpenWrt advertises itself as the DNS server, wal.nut.lan sends the DNS query for rasp.berry.lan to router.nut.lan.
  2. Dnsmasq on router.nut.lan will forward the query to fd82:272a:3c46:0100::1. This will be tunneled to router.berry.lan.
  3. Dnsmasq on router.berry.lan responds to the query, which will be tunneled back to router.nut.lan.
  4. Dnsmasq on router.nut.lan replies to wal.nut.lan with the response from router.berry.lan.
  5. wal.nut.lan connects to rasp.berry.lan using the provided IP address, which will also be tunneled.

How dnsmasq responds to the rasp.berry.lan is also configurable. You can directly set the AAAA record in dnsmasq or use static DHCP leases.