Check if nameserver depends on peer connection #252

Closed
opened 2025-11-20 05:08:36 -05:00 by saavagebueno · 3 comments
Owner

Originally created by @mlsmaycon on GitHub (Dec 12, 2022).

Originally assigned to: @mlsmaycon on GitHub.

Describe the problem
A nameserver configuration that points to a peer or an address behind a routing peer may cause connectivity issues and unwanted behavior.

We should be able to check if the DNS settings depend on a peer connection and only apply it once the connection is live again.

To Reproduce
Steps to reproduce the behavior:

  1. Create a nameserver configuration that points to a peer (peer-a)
  2. Ensure that it is resolving all connections
  3. Share that connection with your peers via distribution groups
  4. Disconnect the peer-a

Expected behavior
DNS resolution should never fail. In the event we should rollback the DNS resolver and wait for peer connection to be established

Additional context
We might need to extend the status recorder system or the dns server

Originally created by @mlsmaycon on GitHub (Dec 12, 2022). Originally assigned to: @mlsmaycon on GitHub. **Describe the problem** A nameserver configuration that points to a peer or an address behind a routing peer may cause connectivity issues and unwanted behavior. We should be able to check if the DNS settings depend on a peer connection and only apply it once the connection is live again. **To Reproduce** Steps to reproduce the behavior: 1. Create a nameserver configuration that points to a peer (peer-a) 2. Ensure that it is resolving all connections 3. Share that connection with your peers via distribution groups 4. Disconnect the peer-a **Expected behavior** DNS resolution should never fail. In the event we should rollback the DNS resolver and wait for peer connection to be established **Additional context** We might need to extend the status recorder system or the dns server
saavagebueno added the bugclient labels 2025-11-20 05:08:36 -05:00
Author
Owner

@EZPC-Matt commented on GitHub (Jan 24, 2023):

I had a Debian based VM today where Netbird had put it's own IP in /etc/resolv.conf as the only nameserver but following a VM reboot the WT0 interface had not yet been created and thus the IP didn't exist on the system.

Netbird therefore couldn't resolve the DNS for it's own control plane in order to bring itself back up.

Just upgraded to 0.12.0, not sure what it was before that.

@EZPC-Matt commented on GitHub (Jan 24, 2023): I had a Debian based VM today where Netbird had put it's own IP in /etc/resolv.conf as the only nameserver but following a VM reboot the WT0 interface had not yet been created and thus the IP didn't exist on the system. Netbird therefore couldn't resolve the DNS for it's own control plane in order to bring itself back up. Just upgraded to 0.12.0, not sure what it was before that.
Author
Owner

@mlsmaycon commented on GitHub (Jan 24, 2023):

After a chat in slack, the issue happened on a Debian 11 with minimal installation and docker CE. It uses the default systemd init system and no external DNS manager.

@mlsmaycon commented on GitHub (Jan 24, 2023): After a chat in slack, the issue happened on a Debian 11 with minimal installation and docker CE. It uses the default systemd init system and no external DNS manager.
Author
Owner

@mlsmaycon commented on GitHub (Jun 16, 2023):

We've improved the unavailability of a DNS server. This should be resolved now

@mlsmaycon commented on GitHub (Jun 16, 2023): We've improved the unavailability of a DNS server. This should be resolved now
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#252