[GH-ISSUE #5361] Sluggish resolution of short hostnames (search domains) on Windows #10460

Open
opened 2026-08-05 01:25:59 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @s-rwe on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5361

Describe the problem

We're running a self-hosted netbird server with some Windows- and Linux-clients, in a test for potential migration from tailscale to netbird.

We don't have any custom Networks or DNS settings in place in our netbird setup - just a bunch of clients/peers that should all be able to reach one another.

While all this works pretty seamlessly with our vanilla out-of-the-box default setup (v.65.1 for server and clients alike), we do notice that resolving simple hostnames to their fqdn via search domain generally hangs for 1-2s on a Windows clients before they succeed. Unless that lookup has already been cached, that is - so after an ipconfig /flushdns it's the same 1-2s lag again next time, otherwise follow-up resolutions of the same short name are fast (for a while anyway).

Basically this:

# Slow - hangs for 1-2s before starting to run for myhost.netbird.selfhosted
ping myhost

# Fast on 2nd time shortly after, since the lookup got cached
ping myhost

# With fqdn given, it's always fast
ping myhost.netbird.selfhosted

It feels like the lookup (or rather the resolution from unqualified name to fqdn) stalls until it eventually works, maybe due to some internal fallback. We do not experience anything similar on side of our Linux clients (Ubuntu).

I don't know if this is any inherent issue with the netbird client, or rather just something Windows-specific. From our current/previous setup with tailscale in comparison, I know that this also explicitly maintains its list of peers with IPs in the hosts-file (C:\Windows\System32\drivers\etc\hosts) - which might be the reason why we didn't experience the same over there (not quite sure though).

But either way, it would be good to have some solution to get around such delays, since otherwise things really just appear quite a bit more sluggish when using netbird. I was not able to find anything off also based on the DNS Troubleshooting guide.

Any hints appreciated on how this could be improved.

Expected behavior

Resolution of simple/short names without unnecessary delay.

Are you using NetBird Cloud?

No, self-hosted.

NetBird version

v.65.1

Is any other VPN software installed?

Tailscale client used to be installed, though the behaviour is still the same also when disabling and/or fully uninstalling it.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting
  • Reviewed DNS Troubleshooting
  • 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 @s-rwe on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5361 **Describe the problem** We're running a self-hosted netbird server with some Windows- and Linux-clients, in a test for potential migration from tailscale to netbird. We don't have any custom Networks or DNS settings in place in our netbird setup - just a bunch of clients/peers that should all be able to reach one another. While all this works pretty seamlessly with our [vanilla out-of-the-box default setup](https://docs.netbird.io/selfhosted/selfhosted-quickstart) (v.65.1 for server and clients alike), we do notice that resolving simple hostnames to their fqdn via search domain generally hangs for 1-2s on a Windows clients before they succeed. Unless that lookup has already been cached, that is - so after an `ipconfig /flushdns` it's the same 1-2s lag again next time, otherwise follow-up resolutions of the same short name are fast (for a while anyway). Basically this: ``` # Slow - hangs for 1-2s before starting to run for myhost.netbird.selfhosted ping myhost # Fast on 2nd time shortly after, since the lookup got cached ping myhost # With fqdn given, it's always fast ping myhost.netbird.selfhosted ``` It feels like the lookup (or rather the resolution from unqualified name to fqdn) stalls until it eventually works, maybe due to some internal fallback. We do not experience anything similar on side of our Linux clients (Ubuntu). I don't know if this is any inherent issue with the netbird client, or rather just something Windows-specific. From our current/previous setup with tailscale in comparison, I know that this also explicitly maintains its list of peers with IPs in the hosts-file (`C:\Windows\System32\drivers\etc\hosts`) - which might be the reason why we didn't experience the same over there (not quite sure though). But either way, it would be good to have some solution to get around such delays, since otherwise things really just appear quite a bit more sluggish when using netbird. I was not able to find anything off also based on the [DNS Troubleshooting guide](https://docs.netbird.io/manage/dns/troubleshooting). Any hints appreciated on how this could be improved. **Expected behavior** Resolution of simple/short names without unnecessary delay. **Are you using NetBird Cloud?** No, self-hosted. **NetBird version** v.65.1 **Is any other VPN software installed?** Tailscale client used to be installed, though the behaviour is still the same also when disabling and/or fully uninstalling it. **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) - [x] Reviewed [DNS Troubleshooting](https://docs.netbird.io/manage/dns/troubleshooting) - [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:25:59 -04:00
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#10460