Confirming How Managed (Automatic) DNS Works on a Routing Peer

I just set up Netbird, and am surprised to find that when I set up a Network via a CIDR (192.168.3.0/24) and assigned a Routing Peer with access to that subnet, DNS queries made from a peer outside the subnet (aka, through the mesh network connection) are routed to Unbound (listening on 192.168.3.1:53) automatically. I can see in Unbound that the requests are coming from the routing peer.

How does the Routing Peer’s local resolver know which local DNS to forward queries to? Does it just copy from the DNS that was previously configured in /etc/resolv.conf?

I’m mostly surprised because I thought that using local DNS would require setting up a Network resource with hostname rather than CIDR, setting up a Network Route to the DNS server, and then adding the DNS server into Netbird as a resolver for the local hostnames.

Thanks for the help! I want to make sure I’m understanding how the DNS works, because you know… DNS is always the problem :slight_smile:

The routing peer has it’s own DNS servers inside of itself, if you use a routing peer and have it redirect traffic based on DNS records (eg, *.home.domain.com) it will use the DNS of the routing peer (Which is given by DHCP on your network)

Well, I just found out that things were NOT working as intended… I had set the Routing Peer node in my internal network to also be an Exit Node, which caused some weird behavior with DNS.

So, sounds like the domain based approach is the correct one, and if you just use a CIDR you need to set up a DNS server in NetBird that is accessible via that CIDR.

However, I want to set up a Network Route for one of my VLANs, and it shares the same domain as my network setup is pretty simplistic. Sounds like I need to use the second approach to not mix Networks with Network Routes.

Any specific reason for the network → network route? Why not use the network for both? Just grab the correct subnet for the VLAN.

Well, I read this: Network Routes - NetBird Docs

I want both remote access to my network from a mobile device, and I want a machine on the LAN to be able to access a remote machine that is only accessible via the NetBird mesh.

I’m not 100% sure what scenarios this caveat applies to.

Scenario A) if I have a domain defined Network that is one-way routing all *.internal domains to multiple VLANs via the Routing Peer, where firewall rules allow the Routing Peer on its VLAN to initiate connections to other VLANs, but not vice-versa. This way I can access all LAN resources via the Routing Peer. Then, I add a Network Route from the same VLAN as the Routing Peer, which would allow the LAN machine to access the mesh. Bad practice or not?

Scenario B) I use CIDR defined Networks for all different VLANs that I want remote access to. I then define a Network Route for the same VLAN as the routing peer. Bad practice?

Scenario C) I use seperate Network Routes for all VLANs, but I think this can’t prevent two way access from some of the VLANs, for example IOT. I think this isn’t what I want, since I want to be able to control which machines are able to ingress into the NetBird mesh.

Thoughts?

Scenario A:
Mixing domain-based networks with network routes can work, but it’s messy and can cause routing/DNS confusion. Not ideal unless you need domain-based routing.

Scenario B:
Using CIDR networks per VLAN + a network route seems to be the most realistic safe way to to this. It’s mostly is the recommended approach for remote access in the market.

Scenario C:
Not recommended if you need to control ingress. As it allows everything by dedault.

TL;DR: CIDR networks + routing peer + selective network routes = simplest, safest setup.