Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS not respect network routes #2653

Open
xan-it opened this issue Sep 26, 2024 · 4 comments
Open

DNS not respect network routes #2653

xan-it opened this issue Sep 26, 2024 · 4 comments

Comments

@xan-it
Copy link

xan-it commented Sep 26, 2024

Describe the problem

We have multiple network routes with a nameserver entry to the same domain in each . If we select only one network route, netbird should use the nameerver from that network because it is the only one reachable from the peer.
It seems that netbird use the first available nameserver for the requested domain even if this is not available from the peer.

To Reproduce

Steps to reproduce the behavior:

  1. Create two or more peers in different networks and create network routes to this networks.
    e.g.:
    peer1 with local IP 172.20.0.1 with network route 172.20.0.0/16 with name lan1
    peer2 with local IP 172.21.0.1 with network route 172.21.0.0/16 with name lan2
    peer3 with local IP 172.22.0.1 with network route 172.22.0.0/16 with name lan3

  2. Install DNS server which can resolve test.testdomain.com in each network and create a nameserver entry in netbord for the same domain in each network.
    e.g.:
    entry 1 with nameserver 172.20.0.253 with the domain testdomain.com
    entry 2 with nameserver 172.21.0.253 with the domain testdomain.com
    entry 3 with nameserver 172.22.0.253 with the domain testdomain.com

  3. On the client select only one network after another and try to resolve test.testdomain.com.
    Only in one network there is a correct result. In the other networks you will get an error that the name can't resolve.

Expected behavior

netbird should use the nameserver reachable by the peer.

Are you using NetBird Cloud?

no, self-hosted

NetBird version

server 0.29.3
client 0.29.4

NetBird status -dA output:

Peers detail:
lan1-pve1.netbird.selfhosted:
NetBird IP: 100.97.19.116
Public key: ...
Status: Connected
-- detail --
Connection type: Relayed
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address: rels://netbird.anon-RZnkf.domain:443
Last connection update: 9 seconds ago
Last WireGuard handshake: 8 seconds ago
Transfer status (received/sent) 3.5 KiB/12.3 KiB
Quantum resistance: false
Routes: -
Latency: 0s

lan2-pve1.netbird.selfhosted:
NetBird IP: 100.97.131.97
Public key: ...
Status: Connected
-- detail --
Connection type: Relayed
ICE candidate (Local/Remote): -/-
ICE candidate endpoints (Local/Remote): -/-
Relay server address: rels://netbird.anon-RZnkf.domain:443
Last connection update: 4 minutes, 50 seconds ago
Last WireGuard handshake: 6 minutes, 12 seconds ago
Transfer status (received/sent) 92 B/6.3 KiB
Quantum resistance: false
Routes: -
Latency: 37.261ms

lan3-pve1.netbird.selfhosted:
NetBird IP: 100.97.140.40
Public key: ...
Status: Connected
-- detail --
Connection type: P2P
ICE candidate (Local/Remote): srflx/srflx
ICE candidate endpoints (Local/Remote): 198.51.100.0:51820/198.51.100.1:51820
Relay server address: rels://netbird.anon-RZnkf.domain:443
Last connection update: 42 minutes, 15 seconds ago
Last WireGuard handshake: 1 minute, 15 seconds ago
Transfer status (received/sent) 4.4 KiB/12.9 KiB
Quantum resistance: false
Routes: -
Latency: 146.6974ms

OS: windows/amd64
Daemon version: 0.29.4
CLI version: 0.29.4
Management: Connected to https://netbird.anon-RZnkf.domain:443
Signal: Connected to https://netbird.anon-RZnkf.domain:443
Relays:
[stun:netbird.anon-RZnkf.domain:3478] is Available
[turn:netbird.anon-RZnkf.domain:3478?transport=udp] is Available
[rels://netbird.anon-RZnkf.domain:443] is Available
Nameservers:
[172.20.0.253:53] for [anon-STYq8.domain] is Available
[172.21.0.253:53] for [anon-STYq8.domain] is Available
[172.22.0.253:53] for [anon-STYq8.domain] is Available
FQDN: peer9.netbird.selfhosted
NetBird IP: 100.97.207.78/16
Interface type: Userspace
Quantum resistance: false
Routes: -
Peers count: 3/3 Connected

Do you face any (non-mobile) client issues?

Screenshots

Additional context

@lixmal
Copy link
Contributor

lixmal commented Sep 26, 2024

Hi @xan-it,

for this to work you will have to put the nameservers for the same domain in one entry here:

image

@xan-it
Copy link
Author

xan-it commented Sep 26, 2024

@lixmal : thank you for your workaround but there I can only add 3 nameservers (I have more then 10) and I can't control the nameservers with distribution groups.

@mgarces mgarces added the dns label Sep 26, 2024
@mgarces
Copy link

mgarces commented Sep 26, 2024

@xan-it can't you add multiple custom Nameservers? I don't understand what you mean "I can't control the nameservers with distribution groups"; what is that you are really trying to achieve?

@xan-it
Copy link
Author

xan-it commented Sep 26, 2024

I will explain the situation more precise.

Network setup:
We have multiple customers with a network each build identically: There is a linux server with a netbird client used as a routing peer to the network and every network has a nameserver which can resolve the same domain "ourinternaldomain.io" to the specific local IPs in that network (so we can e.g. use https://dashboard.ourinternaldomain.io in every network for our convenience).
But the networks have different IP-subnets and the nameservers and webservers have different IPs.

Service technican:
There are several service technican on our site with the rights to support specific customers. These was solved using groups:
E.g. technican1 can support customer1 and customer2. Technican2 can support customer3 and customer4.
That works fine: the technican can only see the networks of the customers he belongs to. The same way we go with the nameservers belonging to the network. They also assigned to the same group.

Goal:
Now the technican wants to support a customer. He starts the netbird client UI and select only the one network of the customer he wants to support. So he not accidentally works in the wrong network.
Now he wants to open the Dashboard in the browser: https://dashboard.ourinternaldomain.io.
But the whole name resolution only works if the first available nameserver (see netbird status above) is on the network the technican selected. If the first available nameserver is on a network which is not selected we get a "can't resolve".

It seems that netbird identifies the availability of the nameserver not respecting the selected networks in the client. Netbird should use the first available nameserver on the selected network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants