[GH-ISSUE #5579] Custom Zone records are not removed when the Netbird client disconnects #10815

Open
opened 2026-08-05 01:27:22 -04:00 by saavagebueno · 4 comments
Owner

Originally created by @sbeaudry-qms on GitHub (Mar 11, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5579

Custom Zones break after disconnection

Custom zones work wonderfully when connected, but when the netbird client (at least in 0.66.3 on Windows 11) disconnects, the zone no longer reverts to the pre-connected state, and name resolution for the zone is broken. I believe that whichever mechanism is being used on the the local adapter to intercept the requests, and redirect them to the netbird server DNS is not being properly cleaned up when disconnecting.

I use custom zone records to specify the netbird IP addresses (100.110,x,x) of known resources on my network that are running the netbird client, to cause netbird clients to communicate with those servers via the netbird IP range when connected. (I believe this is the intended purpose of the Custom Zones).

To Reproduce

Steps to reproduce the behavior:

  1. Select a host/zone/DNS domain that already exists on your network/in the world without netbird (myhost.contoso.local).
  2. from a client, before connecting to netbird, ping the host by name.. name resolution happens immediately via normal DNS, returning a public/private IP address (192.168.1.x)
  3. In the netbird console, Create a Zone that matches a DNS domain that already exists outside of netbird (contoso.local)
  4. In the netbird console, Create a host record in that zone (myhost.contoso.local) and specify a netbird ranged IP address (100.110.x.x)
  5. Connect a netbird client that is scoped to the distribution group the zone applies to.
  6. From the client, ping the host record you created in step 2. Name resolution works perfectly, but this time returns the netbird IP Address of the host (100.110.x.x), as expected.
  7. Disconnect the netbird client.
  8. Try to ping ANY host in the zone that was created. Name resolution will fail.
    • A packet capture will show that all DNS requests for the zone/domain are being sent to 100.110.255.254 via the regular network adapter. Because the netbird adapter is not up, it is not reachable, and ALL DNS for the zone now fails.
  9. The only way to resolve network communication I've found is to reboot the client machine.

** Expected behaviour **

The DNS redirection/interception that is put in place when the netbird connection is brought up should be removed when the connection is terminated/disconnected.

NetBird version
WIndows 11 - Netbird 0.66.3

Is any other VPN software installed?
No

Originally created by @sbeaudry-qms on GitHub (Mar 11, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5579 **Custom Zones break after disconnection** Custom zones work wonderfully when connected, but when the netbird client (at least in 0.66.3 on Windows 11) disconnects, the zone no longer reverts to the pre-connected state, and name resolution for the zone is broken. I believe that whichever mechanism is being used on the the local adapter to intercept the requests, and redirect them to the netbird server DNS is not being properly cleaned up when disconnecting. I use custom zone records to specify the netbird IP addresses (100.110,x,x) of known resources on my network that are running the netbird client, to cause netbird clients to communicate with those servers via the netbird IP range when connected. (I believe this is the intended purpose of the Custom Zones). **To Reproduce** Steps to reproduce the behavior: 1. Select a host/zone/DNS domain that already exists on your network/in the world without netbird (myhost.contoso.local). 2. from a client, before connecting to netbird, ping the host by name.. name resolution happens immediately via normal DNS, returning a public/private IP address (192.168.1.x) 3. In the netbird console, Create a Zone that matches a DNS domain that already exists outside of netbird (contoso.local) 4. In the netbird console, Create a host record in that zone (myhost.contoso.local) and specify a netbird ranged IP address (100.110.x.x) 5. Connect a netbird client that is scoped to the distribution group the zone applies to. 6. From the client, ping the host record you created in step 2. Name resolution works perfectly, but this time returns the netbird IP Address of the host (100.110.x.x), as expected. 7. Disconnect the netbird client. 8. Try to ping ANY host in the zone that was created. Name resolution will fail. - A packet capture will show that all DNS requests for the zone/domain are being sent to 100.110.255.254 via the regular network adapter. Because the netbird adapter is not up, it is not reachable, and ALL DNS for the zone now fails. 10. The only way to resolve network communication I've found is to reboot the client machine. ** Expected behaviour ** The DNS redirection/interception that is put in place when the netbird connection is brought up should be removed when the connection is terminated/disconnected. **NetBird version** WIndows 11 - Netbird 0.66.3 **Is any other VPN software installed?** No
saavagebueno added the triage-needed label 2026-08-05 01:27:22 -04:00
Author
Owner

@sbeaudry-qms commented on GitHub (Mar 11, 2026):

I've done some more investigation into this. The NrptRules are being properly removed from the registry (Get-DnsClientNrptRule shows an empty rules list after the shutdown), but the DnsCache is still serving the stale records. Windows now seems to block restarting the DnsCache to clear/flush the entries.

The only method I've been successful with, short of rebooting the machine, is killing the DnsCache process by PID, and letting windows respawn it (admittedly about as elegant as my singing voice at a karaoke bar). Still, it was better than having to reboot to get my network back. Obviously not a proper solution, but passing it on to maybe save you a few minutes of investigation (and providing the following PowerShell code for anyone else that comes across this issue needing an immediate fix (can't call it a solution).

$dnsPid = (Get-WmiObject Win32_Service -Filter "Name='Dnscache'").ProcessId
Write-Host "Will kill PID: $dnsPid"
Stop-Process -Id $dnsPid -Force

<!-- gh-comment-id:4042736257 --> @sbeaudry-qms commented on GitHub (Mar 11, 2026): I've done some more investigation into this. The NrptRules are being properly removed from the registry (Get-DnsClientNrptRule shows an empty rules list after the shutdown), but the DnsCache is still serving the stale records. Windows now seems to block restarting the DnsCache to clear/flush the entries. The only method I've been successful with, short of rebooting the machine, is killing the DnsCache process by PID, and letting windows respawn it (admittedly about as elegant as my singing voice at a karaoke bar). Still, it was better than having to reboot to get my network back. Obviously not a proper solution, but passing it on to maybe save you a few minutes of investigation (and providing the following PowerShell code for anyone else that comes across this issue needing an immediate fix (can't call it a solution). $dnsPid = (Get-WmiObject Win32_Service -Filter "Name='Dnscache'").ProcessId Write-Host "Will kill PID: $dnsPid" Stop-Process -Id $dnsPid -Force
Author
Owner

@martin1ehm commented on GitHub (Apr 28, 2026):

Any news on this? This seems related to #3468 and #3356 as well. (and #4386 ?)

The NetBird Windows client (v 0.70.0) still appears to leave the Windows DNS Client / Dnscache / NRPT in a broken state after disconnecting, especially after a temporary network interruption while NetBird is connected.

Also, the configured Match Domains do not seem to be respected reliably. In my case, vpn.yourdomain.com is not included in any Match Domain, but after the disconnect/reconnect scenario it still stops resolving through the normal Windows resolver path.

Repro:

  1. Connect NetBird on Windows 11
  2. While NetBird is connected, interrupt the internet connection
  3. Restore the internet connection
  4. Disconnect NetBird
  5. Try to resolve vpn.yourdomain.com

Observed behavior:

ping vpn.mydomain.com
Host not found / cannot resolve

This also breaks communication with the Windows domain environment. (like #2895 ?)
After this happens, the internal windowsdomain.local names that are intentionally configured in NetBird DNS Match Domains no longer resolve either.

As a result, domain-related communication is affected as well, including access to domain controllers, file servers, and other AD-integrated services that rely on the internal DNS zone.

I am looking for a permanent solution for this.

Maybe I missed something in the NetBird DNS/client configuration, but currently the only reliable recovery seems to be restarting the Windows laptop - this is not acceptable for daily use, especially for non-admin users and remote workers.

Is there any known working NetBird Windows client version where this DNS / Match Domains / Dnscache issue does not occur?

(Used AI for translation - sorry)

<!-- gh-comment-id:4333673461 --> @martin1ehm commented on GitHub (Apr 28, 2026): Any news on this? This seems related to #3468 and #3356 as well. (and #4386 ?) The NetBird Windows client (v 0.70.0) still appears to leave the Windows DNS Client / Dnscache / NRPT in a broken state after disconnecting, especially after a temporary network interruption while NetBird is connected. Also, the configured Match Domains do not seem to be respected reliably. In my case, vpn.yourdomain.com is not included in any Match Domain, but after the disconnect/reconnect scenario it still stops resolving through the normal Windows resolver path. Repro: 1. Connect NetBird on Windows 11 2. While NetBird is connected, interrupt the internet connection 3. Restore the internet connection 4. Disconnect NetBird 5. Try to resolve vpn.yourdomain.com Observed behavior: ``` ping vpn.mydomain.com Host not found / cannot resolve ``` This also breaks communication with the Windows domain environment. (like #2895 ?) After this happens, the internal `windowsdomain.local` names that are intentionally configured in NetBird DNS Match Domains no longer resolve either. As a result, domain-related communication is affected as well, including access to domain controllers, file servers, and other AD-integrated services that rely on the internal DNS zone. I am looking for a permanent solution for this. Maybe I missed something in the NetBird DNS/client configuration, but currently the only reliable recovery seems to be restarting the Windows laptop - this is not acceptable for daily use, especially for non-admin users and remote workers. Is there any known working NetBird Windows client version where this DNS / Match Domains / Dnscache issue does not occur? (Used AI for translation - sorry)
Author
Owner

@martin1ehm commented on GitHub (May 8, 2026):

I found a workaround, although I’m not sure why this particular setup works, whether it is intended behavior, or whether it is suitable as a long-term solution.

I added two DNS server entries on the NetBird server:

  1. The internal company DNS (192.168...) as server for all domains.
  2. The exact same DNS server again, but with match domains configured -> windowsdomain.local.

Using only entry 1 or only entry 2 does not solve the issue. The problem only disappears when both entries are configured together.

(I have a static DNS entry in the Windows hosts file pointing to the VPS where my NetBird server is running. However, this alone did not solve the issue.)

I will continue testing this, but so far it looks like it is working.

UPDATE: It doesn't work reliably - Problem still existing with 0.71.0, 0.71.1 and 0.71.2...

<!-- gh-comment-id:4403850387 --> @martin1ehm commented on GitHub (May 8, 2026): I found a workaround, although I’m not sure why this particular setup works, whether it is intended behavior, or whether it is suitable as a long-term solution. I added two DNS server entries on the NetBird server: 1. The internal company DNS (192.168...) as server for all domains. 2. The exact same DNS server again, but with match domains configured -> `windowsdomain.local`. Using only entry 1 or only entry 2 does not solve the issue. The problem only disappears when both entries are configured together. (I have a static DNS entry in the Windows hosts file pointing to the VPS where my NetBird server is running. However, this alone did not solve the issue.) I will continue testing this, but so far it looks like it is working. UPDATE: It doesn't work reliably - Problem still existing with 0.71.0, 0.71.1 and 0.71.2...
Author
Owner

@Enrica-r commented on GitHub (Aug 3, 2026):

I can provide some additional findings from a Windows 11 system running NetBird 0.76.1.

The behavior appears to be related to Windows DNS policy/NRPT entries not being removed when NetBird disconnects.

Environment

  • Windows 11
  • NetBird client: 0.76.1
  • Self-hosted NetBird management
  • Interface type: Userspace
  • NetBird DNS is intentionally used for several custom zones

My NetBird DNS configuration contains, among others:

  • sv.example.ch192.168.30.1:53
  • dev.example.ch192.168.30.1:53
  • martin.example2.ch192.168.179.2:53
  • marcelle.example2.ch192.168.1.2:53

When NetBird is connected, DNS works correctly.

However, after:

netbird down

the Windows DNS policies remain present.

For example:

Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers

still returns:

.dev.example.ch              100.93.255.254
.sv.example.ch               100.93.255.254
.martin.example2.ch       100.93.255.254
.marcelle.example2.ch     100.93.255.254
.netbird.selfhosted           100.93.255.254
...

This remains unchanged even after NetBird reports:

Disconnected

The normal Windows DNS configuration is different and is working correctly:

DNS server: 192.168.102.2

For example, after netbird down:

nslookup dev.example.ch

successfully returns:

Server:  adguard.enrica.example2.ch
Address: 192.168.102.2

Name:    dev.example.ch
Address: 192.168.30.25

However:

Resolve-DnsName dev.guggach.ch

times out, and applications using the Windows DNS resolver cannot resolve the hostname.

This strongly suggests that the remaining Windows DNS policy is intercepting the query before the normal DNS configuration can be used.

Another interesting finding

netbird up --disable-dns does not appear to clean up the existing policy.

After:

netbird down
netbird up --disable-dns

netbird debug config correctly reports:

"disableDns": true

but the existing Windows DNS policies are still present:

.dev.example.ch    100.93.255.254
.sv.example.ch     100.93.255.254
...

So disableDns appears to disable NetBird DNS behavior for the current configuration, but does not remove the DNS policies that were previously installed.

NRPT / policy store observation

Interestingly:

Get-DnsClientNrptRule

returns nothing, while:

Get-DnsClientNrptPolicy

shows the NetBird-related policies.

The following registry policy location also exists:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig

Furthermore, the NetBird debug output contains:

detected GPO DNS policy configuration, using policy store

This may be relevant to why the policies survive disconnect.

Reproduction

The issue is reliably reproducible:

  1. Connect with netbird up
  2. Verify that the custom zones resolve correctly
  3. Run netbird down
  4. Check Get-DnsClientNrptPolicy
  5. The NetBird DNS policies are still present
  6. Resolve-DnsName for the affected custom zones times out
  7. nslookup, explicitly using the local DNS server, still resolves the names successfully
  8. Rebooting Windows clears the problem

This also explains why simply restarting the Windows DNS Client service does not seem to be a practical workaround. The service cannot be stopped normally because other services depend on it, and Restart-Service Dnscache -Force also fails.

The important distinction in my case is that I do want NetBird DNS while connected. The expected behavior is therefore:

  • NetBird connected → NetBird DNS policies active
  • NetBird disconnected → NetBird DNS policies removed and Windows returns to the normal local DNS configuration

At the moment, the second part does not happen.

Hopefully these details help identify where the Windows DNS policy is being installed and why it is not being cleaned up on disconnect.

<!-- gh-comment-id:5167189151 --> @Enrica-r commented on GitHub (Aug 3, 2026): I can provide some additional findings from a Windows 11 system running NetBird 0.76.1. The behavior appears to be related to Windows DNS policy/NRPT entries not being removed when NetBird disconnects. ### Environment * Windows 11 * NetBird client: 0.76.1 * Self-hosted NetBird management * Interface type: Userspace * NetBird DNS is intentionally used for several custom zones My NetBird DNS configuration contains, among others: * `sv.example.ch` → `192.168.30.1:53` * `dev.example.ch` → `192.168.30.1:53` * `martin.example2.ch` → `192.168.179.2:53` * `marcelle.example2.ch` → `192.168.1.2:53` When NetBird is connected, DNS works correctly. However, after: ```powershell netbird down ``` the Windows DNS policies remain present. For example: ```powershell Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers ``` still returns: ```text .dev.example.ch 100.93.255.254 .sv.example.ch 100.93.255.254 .martin.example2.ch 100.93.255.254 .marcelle.example2.ch 100.93.255.254 .netbird.selfhosted 100.93.255.254 ... ``` This remains unchanged even after NetBird reports: ```text Disconnected ``` The normal Windows DNS configuration is different and is working correctly: ```text DNS server: 192.168.102.2 ``` For example, after `netbird down`: ```powershell nslookup dev.example.ch ``` successfully returns: ```text Server: adguard.enrica.example2.ch Address: 192.168.102.2 Name: dev.example.ch Address: 192.168.30.25 ``` However: ```powershell Resolve-DnsName dev.guggach.ch ``` times out, and applications using the Windows DNS resolver cannot resolve the hostname. This strongly suggests that the remaining Windows DNS policy is intercepting the query before the normal DNS configuration can be used. ### Another interesting finding `netbird up --disable-dns` does not appear to clean up the existing policy. After: ```powershell netbird down netbird up --disable-dns ``` `netbird debug config` correctly reports: ```json "disableDns": true ``` but the existing Windows DNS policies are still present: ```text .dev.example.ch 100.93.255.254 .sv.example.ch 100.93.255.254 ... ``` So `disableDns` appears to disable NetBird DNS behavior for the current configuration, but does not remove the DNS policies that were previously installed. ### NRPT / policy store observation Interestingly: ```powershell Get-DnsClientNrptRule ``` returns nothing, while: ```powershell Get-DnsClientNrptPolicy ``` shows the NetBird-related policies. The following registry policy location also exists: ```text HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig ``` Furthermore, the NetBird debug output contains: ```text detected GPO DNS policy configuration, using policy store ``` This may be relevant to why the policies survive disconnect. ### Reproduction The issue is reliably reproducible: 1. Connect with `netbird up` 2. Verify that the custom zones resolve correctly 3. Run `netbird down` 4. Check `Get-DnsClientNrptPolicy` 5. The NetBird DNS policies are still present 6. `Resolve-DnsName` for the affected custom zones times out 7. `nslookup`, explicitly using the local DNS server, still resolves the names successfully 8. Rebooting Windows clears the problem This also explains why simply restarting the Windows DNS Client service does not seem to be a practical workaround. The service cannot be stopped normally because other services depend on it, and `Restart-Service Dnscache -Force` also fails. The important distinction in my case is that I **do want NetBird DNS while connected**. The expected behavior is therefore: * NetBird connected → NetBird DNS policies active * NetBird disconnected → NetBird DNS policies removed and Windows returns to the normal local DNS configuration At the moment, the second part does not happen. Hopefully these details help identify where the Windows DNS policy is being installed and why it is not being cleaned up on disconnect.
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#10815