[GH-ISSUE #5757] DNS Zones overwrite all upstream records instead of being selective #11955

Open
opened 2026-08-05 01:31:52 -04:00 by saavagebueno · 5 comments
Owner

Originally created by @Blackclaws on GitHub (Apr 1, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5757

Describe the problem

This could be more of a feature request than an actual issue. But my expectation for the DNS zone feature was that I would be able to selectively overwrite entries in DNS zones with netbird specific entries.

When adding a zone with a record in Netbird the whole zone becomes usurped and no upstream resolver is contacted for missing records in netbird.

The reason here is that we have some services within a zone that are netbird accessible only, but have a public DNS name for Letsencrypt purposes. We didn't want to add every single ip to the main DNS zone because it makes no sense to publicly resolve these ips.

To Reproduce

Steps to reproduce the behavior:

  1. Have a public DNS Zone with multiple entries
  2. Create the same zone in Netbird with only one record present
  3. See that for the entry not present in netbird REFUSED is returned

Expected behavior

Missing records are forwarded to the upstream resolver and the record from there is returned.

Are you using NetBird Cloud?

Self hosted

NetBird version

0.67.1

Is any other VPN software installed?

No

** Potential Solution **

Allow DNS Zones to be selective on the management side as to whether they usurp the whole zone or just provide custom records for some entries.

Originally created by @Blackclaws on GitHub (Apr 1, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5757 **Describe the problem** This could be more of a feature request than an actual issue. But my expectation for the DNS zone feature was that I would be able to selectively overwrite entries in DNS zones with netbird specific entries. When adding a zone with a record in Netbird the whole zone becomes usurped and no upstream resolver is contacted for missing records in netbird. The reason here is that we have some services within a zone that are netbird accessible only, but have a public DNS name for Letsencrypt purposes. We didn't want to add every single ip to the main DNS zone because it makes no sense to publicly resolve these ips. **To Reproduce** Steps to reproduce the behavior: 1. Have a public DNS Zone with multiple entries 2. Create the same zone in Netbird with only one record present 3. See that for the entry not present in netbird REFUSED is returned **Expected behavior** Missing records are forwarded to the upstream resolver and the record from there is returned. **Are you using NetBird Cloud?** Self hosted **NetBird version** 0.67.1 **Is any other VPN software installed?** No ** Potential Solution ** Allow DNS Zones to be selective on the management side as to whether they usurp the whole zone or just provide custom records for some entries.
saavagebueno added the triage-needed label 2026-08-05 01:31:52 -04:00
Author
Owner

@lixmal commented on GitHub (Apr 1, 2026):

Have you tried adding a fallback resolver (Nameservers -> ALL match domains)? That would work like you expect. The natural fallback to the OS's resolver is not implemented on all platforms yet

<!-- gh-comment-id:4168658327 --> @lixmal commented on GitHub (Apr 1, 2026): Have you tried adding a fallback resolver (Nameservers -> ALL match domains)? That would work like you expect. The natural fallback to the OS's resolver is not implemented on all platforms yet
Author
Owner

@Blackclaws commented on GitHub (Apr 1, 2026):

That does indeed work, though we so far didn't register a general nameserver in netbird as we saw no need and also have local nameservers in the local networks that would then not be queried.

Which platforms are still missing? I'm on Linux and would have expected systemd-resolved to be supported for fallback, but maybe not?

<!-- gh-comment-id:4168737511 --> @Blackclaws commented on GitHub (Apr 1, 2026): That does indeed work, though we so far didn't register a general nameserver in netbird as we saw no need and also have local nameservers in the local networks that would then not be queried. Which platforms are still missing? I'm on Linux and would have expected systemd-resolved to be supported for fallback, but maybe not?
Author
Owner

@lixmal commented on GitHub (Apr 1, 2026):

Which platforms are still missing? I'm on Linux and would have expected systemd-resolved to be supported for fallback, but maybe not?

Currently implemented: macOS and Linux with plain /etc/resolv.conf (no systemd-resolved etc available)

<!-- gh-comment-id:4169052919 --> @lixmal commented on GitHub (Apr 1, 2026): >Which platforms are still missing? I'm on Linux and would have expected systemd-resolved to be supported for fallback, but maybe not? Currently implemented: macOS and Linux with plain /etc/resolv.conf (no systemd-resolved etc available)
Author
Owner

@InternetWorkAcct commented on GitHub (Apr 8, 2026):

The UI says DNS Zone, that implies that the Netbird DNS server is the authoritative resolver for this subdomain.

For individual names you should be using Resources, that does exactly what you describe.

<!-- gh-comment-id:4205651679 --> @InternetWorkAcct commented on GitHub (Apr 8, 2026): The UI says **DNS Zone**, that implies that the Netbird DNS server is the authoritative resolver for this subdomain. For individual names you should be using Resources, that does exactly what you describe.
Author
Owner

@Blackclaws commented on GitHub (Apr 8, 2026):

The UI says DNS Zone, that implies that the Netbird DNS server is the authoritative resolver for this subdomain.

For individual names you should be using Resources, that does exactly what you describe.

It doesn't do the same thing. Close but not quite.

Resources work fine if you have a network that forwards request to given dns names through its routing peers. But in this case I'd like to rebind the DNS name to instead point to the netbird peer address instead of the public ip address.

Hosts that aren't within netbird will see the public ip and connect via that and peers within netbird get the netbird peer's address instead. This can of course be handled by adding all entries to a zone, but since there is no zone-transfer functionality that isn't ideal (another workaround is split horizon DNS but that is also a mess to support). Given that a fallback DNS resolver works (if one is pushed to netbird peers) this is also not the intended behavior that you describe.

Essentially what seems to be missing is to fallback to the OS resolver for systemd-resolved which at this point isn't supported.

<!-- gh-comment-id:4205696307 --> @Blackclaws commented on GitHub (Apr 8, 2026): > The UI says **DNS Zone**, that implies that the Netbird DNS server is the authoritative resolver for this subdomain. > > For individual names you should be using Resources, that does exactly what you describe. It doesn't do the same thing. Close but not quite. Resources work fine if you have a network that forwards request to given dns names through its routing peers. But in this case I'd like to rebind the DNS name to instead point to the netbird peer address instead of the public ip address. Hosts that aren't within netbird will see the public ip and connect via that and peers within netbird get the netbird peer's address instead. This can of course be handled by adding all entries to a zone, but since there is no zone-transfer functionality that isn't ideal (another workaround is split horizon DNS but that is also a mess to support). Given that a fallback DNS resolver works (if one is pushed to netbird peers) this is also not the intended behavior that you describe. Essentially what seems to be missing is to fallback to the OS resolver for systemd-resolved which at this point isn't supported.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11955