fix(windows): set search domain on WinTUN interface

[thomaseizinger]

In order for search-domains to work on Windows, we need to set the SearchList registry key for our interface. This will result in Windows sending us a DNS query with the expanded domain name from the search list which we can then process like normal DNS queries.

Related: #8410

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 13, 2025 3:32am

[Copilot]

Pull Request Overview

This PR fixes the Windows search domain handling by setting the SearchList registry key on the WinTUN interface.

• Updated the activate function signature to accept a search_domain parameter and adjusted its usage.
• Added a new set_search_domain_on_interface function to set (or unset) the search domain in the Windows registry.

Comments suppressed due to low confidence (2)

rust/headless-client/src/dns_control/windows.rs:220

• Verify that setting an empty string for 'SearchList' actually unsets the search domain on all target Windows versions. Some versions might require the key to be removed instead.

let search_list = search_domain.map(|d| d.to_string()).unwrap_or_default(); // Default to empty string in order to "unset" the search domain.

rust/headless-client/src/dns_control/windows.rs:139

• [nitpick] Consider updating the function documentation for 'activate' to include details about the new search_domain parameter for clarity on its usage.

fn activate(dns_config: &[IpAddr], search_domain: Option<DomainName>) -> Result<()> {

[thomaseizinger]

My testing confirms that this works but there is a caveat: Because of the interface order, any other connection-specific DNS suffixes will no longer take effect.

For example:

• Ethernet defines a local DNS suffix of example.com
• Firezone starts and applies a DNS suffix of company.net to the WinTUN adapter

Resolving server to server.company.net will work but resolving computer.example.com will not work because Windows takes the NXDOMAIN answer for computer.example.com that we send as authoritive.

[thomaseizinger]

This appears to be a bug (or stupid behaviour) in Windows, at least the behaviour doesn't make any sense to me. This is the configuration on my VM:

(I've temporarily overridden the DNS suffix of my adapter to google.com).

I can ping app which resolves to the configured resource app.example.com, meaning Windows correctly appends the search domain and passes the query to Firezone.

If I try to ping maps (which should resolve to maps.google.com), I get "Ping request could not find host maps". I can also see in the event viewer that it is only generating a DNS query for maps.example.com. That gets passed-through by connlib to the upstream resolver which then answers with NXDOMAIN. And that is where Windows just stops. It doesn't try the next DNS suffix in the list.

This is contrary to e.g. MacOS where all search domains are attempted. Granted though, MacOS automatically appends the previous search domain(s) to our resolver. If I emulate this, e.g. also add google.com as a search domain to our network adapter, then this works.

What appears to be happening is that Windows picks a single adapter and only tries to use the search domains on this adapter. So what we might have to do is listen for network changes of other connection-specific DNS suffixes and append those to our search list as well to make sure they keep working when Firezone connects.

[jamilbk]

What appears to be happening is that Windows picks a single adapter and only tries to use the search domains on this adapter. So what we might have to do is listen for network changes of other connection-specific DNS suffixes and append those to our search list as well to make sure they keep working when Firezone connects.

Yeah this is kinda what happens with the upstream resolvers received over DHCP. If we receive new ones, for example, that's a "network change" event and we should update our upstream resolvers with them.

I suspect (ideally) we would need something similar for search domains. macOS seems to do it for us but not sure about the other OSes.

That said, I don't think this would cause an issue in the wild, as long as we don't set any search domain when the admin hasn't entered one in the portal.

[jamilbk]

See #8430