* docs: document that a primary nameserver is exclusive on Windows
A peer with a primary nameserver now gets a Name Resolution Policy Table rule
covering every namespace, so all resolution goes through NetBird and nowhere
else. Without it Windows queries every adapter's resolvers in parallel and keeps
whichever answer arrives first, which leaks queries to the local network and lets
another resolver answer for a name NetBird is authoritative for.
Two consequences worth knowing before it surprises someone:
- Zones only the local network resolves stop working while connected, unless
they are declared as match domains. A more specific rule takes precedence, so
declaring the zone is the fix. `.local` is exempt, so multicast DNS is
unaffected.
- Short names depend on which adapter's suffix Windows tries first, and it stops
at the first "no such name" rather than continuing down the list. On
domain-joined machines the machine's own domain wins that first attempt, so a
short name can fail while its fully qualified form resolves.
Placed next to the existing macOS note in the same section, since both are about
what a primary nameserver does beyond catching unmatched queries, and next to the
existing warning about emptying match domains, which the suffix caveat explains
the other half of.
Also documents NB_USE_LEGACY_DNS_RESOLUTION, which restores the old behaviour on
a peer.
* docs: correct how Windows expands short names, and say from which version
Two fixes to the notes added in the previous commit.
The short-name mechanism was described wrongly. Windows does not stop at the
first suffix that misses: it walks the whole suffix list of the preferred
interface, and what it will not do is fall through to another interface's
suffixes. Measured on a Windows 11 machine — with NetBird's adapter preferred, a
list of {fritz.box, netbird.cloud} resolves a name that only exists under the
second entry; with the metric raised so the physical adapter wins, the same name
fails because only that adapter's single suffix is ever tried. The practical
advice changes with it: declaring the local zone with search domains enabled puts
both suffixes in one list, which is what makes short names work either way.
Both notes now say the exclusive behaviour arrives in client v0.78.0 and what
earlier clients did instead, so the page reads correctly for someone still on
0.77, and the environment variable is marked with the version that introduces it.
* docs: say that exclusive resolution is what breaks short names on Windows
The suffix-search behaviour is not Windows' own: without the catch-all NRPT
rule Windows keeps searching the other adapters' suffix lists, and the short
name resolves. Gate the note to v0.78.0 and point at it from the exclusivity
note, so both texts agree on what the change costs.
Adds docs for env variables for logging (including the new NB_LOG_DISABLE_ROTATION) and troubleshooting using external logging rotation (describing also new detection behavior).
Riccardo Manfrin