[GH-ISSUE #5170] Wildcard DNS records from authoritative DNS fail to resolve when using custom zones #10023

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

Originally created by @Westie on GitHub (Jan 24, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5170

Describe the problem

Wildcard DNS records from authoritative DNS fail to resolve when using custom zones.

Essentially, Netbird has broken DNS resolution for wildcard records, where those wildcard records are described outside of Netbird for a particular custom zone, such as the public internet.

To Reproduce

  1. Ensure that Netbird is turned OFF
  2. Set up a zone on a globally accessible authoritative DNS server, such as test.tld
  3. On that authoritative DNS server, set up a wildcard A record such as *.test.tld to point to something like 127.0.0.1 and short TTL
  4. Ensure that with Netbird disabled, you are able to ping a previously unresolved record - you should be able to resolve/ping lol.test.tld for example
  5. Create custom zone for test.tld within Netbird, and ensure that clients can resolve that custom zone
  6. Create custom zone entry bananas.test.tld within Netbird, and that it resolves to 127.0.0.2
  7. Connect to self-hosted Netbird
  8. Attempt to ping bananas.test.tld, this correctly resolves to 127.0.0.2
  9. Attempt to ping apples.test.tld, this does not resolve at all

This also appears to affect nested wildcard domains - *.orange.test.tld fails to resolve within Netbird if that is set up as a wildcard record in my authoritative DNS server

A work around is to create a wildcard record locally within Netbird, but this is not a long term fix.

Expected behavior

I would expect both lol.test.tld and apples.test.tld to resolve to *.test.tld that is on the authoritative DNS server, which would be 127.0.0.1

Are you using NetBird Cloud?

Self hosted

NetBird version

0.64.1

Is any other VPN software installed?

No

Debug output

Not required

Screenshots

Not required

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @Westie on GitHub (Jan 24, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5170 **Describe the problem** Wildcard DNS records from authoritative DNS fail to resolve when using custom zones. Essentially, Netbird has broken DNS resolution for wildcard records, where those wildcard records are described outside of Netbird for a particular custom zone, such as the public internet. **To Reproduce** 1. Ensure that Netbird is turned OFF 2. Set up a zone on a globally accessible authoritative DNS server, such as `test.tld` 3. On that authoritative DNS server, set up a wildcard A record such as `*.test.tld` to point to something like `127.0.0.1` and short TTL 4. Ensure that with Netbird disabled, you are able to ping a previously unresolved record - you should be able to resolve/ping `lol.test.tld` for example 5. Create custom zone for `test.tld` within Netbird, and ensure that clients can resolve that custom zone 6. Create custom zone entry `bananas.test.tld` within Netbird, and that it resolves to `127.0.0.2` 7. Connect to self-hosted Netbird 8. Attempt to ping `bananas.test.tld`, this correctly resolves to `127.0.0.2` 8. Attempt to ping `apples.test.tld`, this does not resolve at all This also appears to affect nested wildcard domains - `*.orange.test.tld` fails to resolve within Netbird if that is set up as a wildcard record in my authoritative DNS server A work around is to create a wildcard record locally within Netbird, but this is not a long term fix. **Expected behavior** I would expect both `lol.test.tld` and `apples.test.tld` to resolve to `*.test.tld` that is on the authoritative DNS server, which would be `127.0.0.1` **Are you using NetBird Cloud?** Self hosted **NetBird version** 0.64.1 **Is any other VPN software installed?** No **Debug output** Not required **Screenshots** Not required **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [X] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [X] Checked for newer NetBird versions - [X] Searched for similar issues on GitHub (including closed ones) - [X] Restarted the NetBird client - [X] Disabled other VPN software - [X] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:24:21 -04:00
Author
Owner

@Westie commented on GitHub (Jan 24, 2026):

I suspect the issue is related to https://github.com/netbirdio/netbird/pull/5145

<!-- gh-comment-id:3794459382 --> @Westie commented on GitHub (Jan 24, 2026): I suspect the issue is related to https://github.com/netbirdio/netbird/pull/5145
Author
Owner

@lixmal commented on GitHub (Jan 24, 2026):

I think you're missing setting up an upstream nameserver (dashboard -> nameservers) for that zone if you want netbird's resolver to fall through for unknown records

<!-- gh-comment-id:3794641309 --> @lixmal commented on GitHub (Jan 24, 2026): I think you're missing setting up an upstream nameserver (dashboard -> nameservers) for that zone if you want netbird's resolver to fall through for unknown records
Author
Owner

@Westie commented on GitHub (Jan 24, 2026):

I think you're missing setting up an upstream nameserver (dashboard -> nameservers) for that zone if you want netbird's resolver to fall through for unknown records

@lixmal That resolve things in a suitable manner, however it shouldn't need to, imho.

<!-- gh-comment-id:3795033858 --> @Westie commented on GitHub (Jan 24, 2026): > I think you're missing setting up an upstream nameserver (dashboard -> nameservers) for that zone if you want netbird's resolver to fall through for unknown records @lixmal That resolve things in a suitable manner, however it shouldn't need to, imho.
Author
Owner

@lixmal commented on GitHub (Jan 24, 2026):

@CodeAdminDe you shouldn't use nslookup, it's not aware of macOS DNS configuration beyond /etc/resolv.conf

<!-- gh-comment-id:3795043051 --> @lixmal commented on GitHub (Jan 24, 2026): @CodeAdminDe you shouldn't use nslookup, it's not aware of macOS DNS configuration beyond /etc/resolv.conf
Author
Owner

@Westie commented on GitHub (Jan 24, 2026):

@CodeAdminDe scutil --dns is more appropriate for debugging imho

<!-- gh-comment-id:3795085414 --> @Westie commented on GitHub (Jan 24, 2026): @CodeAdminDe `scutil --dns` is more appropriate for debugging imho
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#10023