Why does a Windows host broadcast an LLMNR or NBT-NS query after DNS returns NXDOMAIN?

## What actually happens on the wire A Windows host resolving a short name walks a chain of mechanisms, and DNS is only one link in it. Roughly: the local resolver cache, the `hosts` file, the configured DNS servers (with the connection's search suffixes appended), and then — if all of that produced nothing — a set of **link-local** name protocols that ask the network segment directly. Those fallbacks are: | Protocol | Transport | Destination | Names | |---|---|---|---| | LLMNR | UDP 5355 | multicast `224.0.0.252` / `FF02::1:3` | any single-label name | | NBT-NS | UDP 137 | subnet broadcast | 15-character NetBIOS names plus a service suffix | | mDNS | UDP 5353 | multicast `224.0.0.251` / `FF02::FB` | names under `.local` | The defining property is that **there is no server**. An LLMNR query is not sent to anything that has been designated as an authority; it is thrown at the whole link, and whichever listener replies first is believed. LLMNR queries are sent with an IP TTL of 1 so they cannot be routed, and NBT-NS uses subnet broadcast, which routers do not forward either. That is why the exposure is scoped to the segment: what matters is what is plugged into the same link, not what is reachable across the estate. ## Why NXDOMAIN does not end resolution The intuition that trips people up is treating DNS as *the* name service. It is not; on Windows it is one step of several, and `NXDOMAIN` is a well-formed, truthful answer meaning "the zone I am authoritative for does not contain that name". It says nothing about whether some other mechanism might know the name, so the resolver moves on to the next mechanism. Nothing has gone wrong at this point. The DNS server behaved correctly, the resolver behaved as specified, and no packet anywhere has been forged. ## Which names actually get here Because the fallback fires only after DNS has denied the name, the traffic on this path is made almost entirely of names that **do not exist**: - typos — a user types `\\fileserv01` instead of `\\fileserver01` - stale mapped drives and shortcuts reconnecting to hosts retired long ago - names in old logon scripts and printer configurations - `wpad`, looked up automatically by hosts with proxy auto-detection enabled - `.local` service discovery from applications and printer drivers On a busy user segment this is a continuous trickle, not a rare event, and it needs no user to make a mistake in the moment. ## Why this is a security subject at all Asking a question is harmless; the problem is what the protocols do with the answer. LLMNR, NBT-NS and mDNS carry no authentication, no signature and no concept of who owns a name. Any device that can put a packet on the link — including one with no account in the directory at all, such as a vendor's installed appliance or a managed print controller — may answer. The client accepts the reply and then does what it was always going to do with the name: open a connection to the address it was given. The device that answered has not exploited anything; it simply told the truth-shaped lie that the protocol invites, and the client walked to it. ## Reading a single lookup The code fragment shows one lookup end to end: the DNS question and its authoritative denial, the two link-local queries that follow, an answer from a host on the segment, and the client's own outbound connection to the address it was handed. Note that the DNS exchange and the LLMNR exchange are *different protocols*: nothing was inserted into a DNS cache, and no DNS message was tampered with. ## The same packets, benign In a small office where a printer is discovered over mDNS and nothing else provides that function, these are the intended packets doing their intended job. The protocol is not a bug. Whether it is an exposure depends on who else shares the link and which names the hosts are asking for.