Windows: DNS Client service (Dnscache) high CPU usage (multiple cores)

[deadbeef84]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Client / Agent

Deployment type

Self-hosted - quickstart script

Operating system or environment

Windows

NetBird version and upgrade status

Client: 0.81.3 (and also 0.65.0)
Management: 0.60.5
Signal: 0.60.5
Relay: 0.60.5 (?)
Dashboard: 0.60.5 (?)

Did this work before?

Not sure

Regression details

No response

Summary

On Windows, while NetBird is connected to a large network, the Windows DNS Client service (svchost hosting Dnscache) uses 1–5 CPU cores. The load comes from NetBird's network adapter enumeration, not from DNS lookups.

There's also several thousand DNS requests per second to the management dns name, spamming my network DNS server.

I believe this is something that started happening recently, but I cant say exactly what caused it.

• I first noticed the issue on my computer when running client 0.65.0. I have been running it for quite some time without any issues. Updating to latest version 0.81.3 didn't resolve the issue.
• In the past week I upgraded the client on many of the other peers (linux servers). They were upgraded from 0.39.1 to 0.80.0, and some from 0.60.5 to 0.80.0. This is my best guess as to what triggered the issue on my computer, but I really cant say for sure.

Current behavior

I've tried enabling lazy connections in the client, but that did not solve the issue (I believe server has it disabled). After forcing client to use relay (NB_FORCE_RELAY), the issue went away.

This is from Claudes analysis of the issue:

Summary

Every ICE agent creates its own stdnet.Net, so the 30-second interface cache in stdnet always starts empty. Each new agent therefore runs a full enumeration. On Windows that is one GetAdaptersAddresses call for net.Interfaces() plus one more per adapter for Addrs(). Go calls GetAdaptersAddresses without GAA_FLAG_SKIP_DNS_SERVER / GAA_FLAG_SKIP_DNS_INFO, so each call also asks the DNS Client service for every adapter's DNS settings. With a few hundred peers creating agents, the DNS Client service stays busy all the time.

Expected behavior

The ICE agents should share one interface cache, so that the 30 s updateInterval limits enumeration across all agents instead of per agent. Adapter enumeration on Windows shouldn't load the DNS Client service in proportion to peer count or signaling traffic.

Steps to reproduce

1. Windows client on 0.81.3, joined to a network with a few hundred peers where most connections end up relayed. Including some peers on 0.60.x makes the effect larger.
2. Watch Dnscache CPU: Get-CimInstance Win32_PerfFormattedData_PerfProc_Process | ? IDProcess -eq (Get-CimInstance Win32_Service -Filter "Name='Dnscache'").ProcessId
3. Compare against netbird down, and against NB_FORCE_RELAY=true.

Environment and topology

• Client: NetBird 0.81.3, Windows 11 Home (build 26200), userspace interface, self-hosted management
• Peers: 257 in the network, about 200 connected (about 170 relayed, about 30 P2P, the rest idle or connecting)
• DNS: NetBird is not managing DNS on this host (0 nameservers, no NRPT rules, no DNS servers set on wt0)
• Adapters: 4 visible (wt0, Wi-Fi, Bluetooth PAN, WSL Hyper-V vEthernet)
• Remote peers run a mix of versions: about 70 on 0.80.0, 26 on 0.60.5, 23 on 0.39.1, and a few others

Self-hosted details, if available

quickstart / docker compose

Logs, status output, or debug evidence

N/A

Related issues or discussions

Closest issue I've found is #4549, but I'm not seeing the errors, only high cpu usage. I don't think they are the same.

Impact

Set NB_FORCE_RELAY=true in the NetBird service environment (HKLM\SYSTEM\CurrentControlSet\Services\Netbird, Environment multi-string value) and restart the service.

Additional context

More from Claude troubleshooting:

Observed

DNS Client service CPU, sampled once per second (100% = one core, 20 logical cores):

Client state	DNS Client CPU	NetBird CPU
Disconnected (netbird down)	0–60%	–
Connected (default settings)	65–536%, average 270% over 40 s	average 59%
Connected, NB_LAZY_CONN=true	about the same (average 270%)	about the same
Connected, NB_FORCE_RELAY=true	average 2% (after about 20 s)	average 2%

DNS Client spikes line up with NetBird's own CPU bursts. Forcing relay mode, which stops ICE, removes the load completely. Lazy connections had no effect, because the remote peers keep connecting.

Isolating the cause

With NetBird stopped, I loaded the DNS Client service with two kinds of calls:

Load	Rate	DNS Client CPU
Adapter enumeration (NetworkInterface.GetAllNetworkInterfaces(), which wraps GetAdaptersAddresses)	about 130 calls/s	63–107%
Name resolution (Dns.GetHostAddresses of a cached name)	about 4,300 calls/s	7–30%

Adapter enumeration costs roughly 1,000× more DNS Client CPU per call than a cached lookup. The cost of DNS lookups during ICE (STUN/TURN URLs) is small in comparison.

Code path (v0.81.3)

1. Every ICE agent gets a new stdnet.Net:
   • client/internal/peer/ice/agent.go#L42 calls newStdNet(...), which calls stdnet.NewNet(...) (client/internal/peer/ice/stdnet.go#L11-L12)
2. The interface cache lives on that instance and starts empty, so the 30 s updateInterval never applies to a new agent:
   • client/internal/stdnet/stdnet.go#L180-L190
3. Each enumeration is 1 + N GetAdaptersAddresses calls:
   • client/internal/stdnet/discover_pion.go#L12-L36: net.Interfaces(), then oif.Addrs() for each interface
   • In Go's net/interface_windows.go, both interfaceTable and interfaceAddrTable call adapterAddresses(). That function uses GAA_FLAG_INCLUDE_PREFIX | GAA_FLAG_INCLUDE_GATEWAYS, which does not skip DNS server or DNS suffix information.
4. Agents are created often:
   • client/internal/peer/worker_ice.go#L223 (reCreateAgent), on every remote offer with a new session ID. Remote peers on 0.60.x send one every 30–45 s for every peer they aren't connected to over P2P.
   • client/internal/peer/guard/ice_monitor.go#L81, every 5 minutes (minor)

For scale: in a 13-minute window this client received about 1,400 offers. 23 peers on 0.39.1 sent 791, 26 peers on 0.60.5 sent 547, and about 70 peers on 0.80.0 sent about 70. Earlier, while this host still ran 0.65.0, the log showed about 14,800 sent offers per hour and about 13,000 received answers per hour.

Suggested fix

• Create one stdnet.Net, or at least one shared interface cache, per engine, and pass it to every ICE agent and the ICE monitor. Invalidate it on network change events.
• Optionally, on Windows, replace net.Interfaces() + Addrs() in pionDiscover with a single golang.org/x/sys/windows.GetAdaptersAddresses call that passes GAA_FLAG_SKIP_DNS_SERVER | GAA_FLAG_SKIP_DNS_INFO | GAA_FLAG_SKIP_MULTICAST | GAA_FLAG_SKIP_ANYCAST. That builds the interface and address list in one cheap call.

[JonathanWillis]

Have you tried to install KB5132061 (windows update, November patches) , I did this and rebooted, and the DNS CPU issue went away. I don't use Netbird but this issue was linked to from a similar CPU issue on tailscale. It seemed to have been caused by either the September/October cumulative patches