Open bbaumgartl opened 1 year ago
I tried the same configuration on an AD joined Windows 10 machine. DNS resolution for netbird works, but the local AD domain doesn't resolve anymore. It looks like netbird changes the DNS configuration (in the adapter properties) from Append primary and connection specific DNS suffixes
to Append these DNS suffixes (in order)
(like it is described here https://answers.uillinois.edu/illinois/page.php?id=114224). This somehow means that Windows is only using the suffixes from this list and on a Windows AD DC this seems to have no effect at all (after changing the setting manually while testing it somehow worked but reconnecting netbird broke it again).
I tried two different manual dns configurations with netbird connected:
Append primary and connection specific DNS suffixes
and setting DNS suffix for this connection
on the wt0
adapter to netbird.cloud
. This appends netbird.cloud
to the DNS Suffix Search List
in ipconfig /all
.domain.local
to Append these DNS suffixes (in order)
after netbird added netbird.cloud
to the list.Both seem to work (local AD domain and netbird domain are added to the search list and can be resolved) on the Windows AD DC and Windows 10 machine. Maybe one could be a possible solution?
Another thing i noticed is that connecting netbird registers the netbird IP address in the local DNS server. This causes local network clients to sometimes get the netbird IP instead of the local IP and thus can't connect to the server. There is an option in the adapter properties (Register this connection's addresses in DNS
) which should avoid this. Maybe this is something that can be set after the adapter is created?
Yes, waiting for that fix as well... This makes NetBird effectively unusable in AD environment, because short names are usually heavily utilized in avarage business usecases (seems that even some Win10/11 domain communication itself expects AD servers to be accessible by their short name).
Btw. I think the solution 1. ("Append primary and connection specific DNS suffixes"
) is proper one
Can confirm this is an issue in AD environments. The suggestions above did fix these issues, however, they are temporary (upon reboot or restarting the netbird client). Would love to roll this solution out but this is a major hurdle.
I think this is already resolved for a long time. Have you tried to install current version and configure DNS properly on the server side?
I just briefly checked it and it seems that the first two points (windows server netbird dns resolution, ad joined windows machine local dns resolution) seem to work now.
The third point (netbird ip is registered in the local domain as ip address) seems to be still an issue.
"The third point (netbird ip is registered in the local domain as ip address) seems to be still an issue."
This is standard behaviour for windows: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/enable-disable-dns-dynamic-registration
"Windows supports Domain Name System (DNS) updates per RFC 2136. By default, this behavior is enabled for Windows DNS clients."
You could disable this via GPO: Computer Configuration > Administrative Templates > Network > DNS Client > Dynamic Update Set it to disabled:
I came across this issue and have the same issue on all AD joined machines (Windows 10/11, Server OS). All Netbird specific DNS settings are ignored on AD joined or Entra-ID hybrid joined machines. WORKGROUP or Entra-ID only joined machines work fine.
Looks like the NRPT Rules are ignored: Get-DnsClientNrptRule
the default dns search domain, in my case onetpg (Example: server01.onetpg) isn't working
Added nameservers like this:
nslookup or Resolve-DnsName work if you specify the Netbird default DNS IP:
It works on machines without domain join:
I found some hints in a Tailscale issue.
The Nrpt-Rule Netbird creates, is ignored if this key exists which is the default in every Active Directory domain, even without any DNS client specific GPOs applied (I tested it...)
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig
From the documentation: "<4> Section 2.2.2.1: The Name key specification is Software\Policies\Microsoft\WindowsNT\DNSClient\DnsPolicyConfig{Name}. In the presence of both specified keys, Windows ignores the System\CurrentControlSet\services\Dnscache\Parameters key."
So, the NrptRule is ignored: (_Computer\HKEY_LOCALMACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\DnsPolicyConfig\NetBird-Match)
Steps to test:
Restart-Service Netbird
or reboot the machinePossible solution Creating DNS Client NRPT Rule like this doesn't work ❌:
Add-DnsClientNrptRule -Namespace "onetpg" -NameServers "100.116.255.254"
Get-DnsClientNrptRule -Name "{265F11C4-B797-48F6-BF9D-24CFD59DC369}"
I think we need a DnsClientNrptPolicy I think but I'm unsure how to create them correctly... there is no Add-DnsClientNrptPolicy commandlet
I created registry key manually and it works :)
My Nebird domain suffix is onetpg (Example: server01.onetpg so it's: _Name=hex(7):2e,00,6f,00,6e,00,65,00,74,00,70,00,67,00,00,00,00,00 = **.onetpg**_
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig\Netbird-onetpg]
"ConfigOptions"=dword:00000008
"Name"=hex(7):2e,00,6f,00,6e,00,65,00,74,00,70,00,67,00,00,00,00,00
"IPSECCARestriction"=""
"GenericDNSServers"="100.116.255.254"
"Version"=dword:00000002
GPO - Group Policy
Proposed fix @mlsmaycon:
Infos
@mlsmaycon did you have a chance to look at this? I bet this could block a rollout for many corps with Windows environments.
It seems like that the netbird search domain is ignored on a Windows Server Active Directory Domain Controller.
After connecting netbird the log states that the search domain was added:
But it does not show up in
ipconfig /all
underDNS Suffix Search List
orConnection-specific DNS Suffix
:And DNS queries with only the hostname fail:
Using the FQDN does work though: