Why is calling an LLMNR name-answer attack 'DNS cache poisoning' the wrong classification?

## Taking the label apart "DNS cache poisoning" asserts three things, and in this event each one is wrong. **It was not poisoning.** Poisoning means getting a false record accepted and stored by a caching resolver so that later, independent lookups return it. Nothing here was inserted into a DNS cache. The client stored a link-local answer in its own resolver cache for a short lifetime; the corporate resolver's cache is untouched, and every other host on the network is unaffected until it makes the same doomed query itself. **Nothing was forged.** A forgery imitates a message the sender was not entitled to send — a spoofed source, a guessed transaction identifier, an unauthorised signature. An LLMNR response is none of those. The responder sent a well-formed message in a protocol that explicitly invites any host on the link to answer, from its own address, in reply to a query addressed to everyone. It is a lie in the sense that the assertion is untrue; it is not a forgery in the sense that any protocol rule was broken. There is no rule to break, which is the whole point. **It was not DNS.** The DNS server received a question and returned `NXDOMAIN`, which was correct. The resolver then continued down the chain, which is specified behaviour. Every component did what it was designed to do, and the outcome was still an authentication-bearing connection to a machine of a stranger's choosing. ## Why the misclassification is expensive A wrong classification survives because it is close enough to feel right, and it costs you in remediation. If the finding says DNS poisoning, the plausible responses are: enable DNSSEC validation, restrict recursion, harden the resolvers, review the zones, shorten TTLs. Each of those is defensible work and **none of them changes anything here**. DNSSEC deserves its own sentence, because it is the first thing a senior engineer reaches for. DNSSEC authenticates DNS answers, including authenticated denial of existence via NSEC or NSEC3. Applied here, it would cryptographically prove that the name does not exist — which is *precisely the condition that triggers the fallback*. A fully validating resolver makes the trigger more trustworthy and does not touch the behaviour that follows. The honest classification names the mechanism: a link-local name-resolution protocol without authority, enabled by default, consulted for names DNS has already denied, on a segment shared with devices you do not control. That framing points at the actual levers — which is a different conversation, and one this leaf deliberately leaves to the people who own the removal decision. ## The conversation with the network owner The common objection is: *"DNS is authoritative here. Nothing else resolves."* Both halves can be true of the namespace and still miss the point. DNS is authoritative for the names it holds. The fallback fires for the names it does **not** hold. Authority over a namespace and being the only mechanism a host consults are different properties, and only the first one is under the network owner's control. The demonstration that ends the argument is a lookup of a name nobody has ever registered: the DNS question, the denial, and then the multicast query leaving the host anyway, addressed to the segment. ## The same behaviour, correctly classified as normal The complement is worth holding in mind because it stops the classification swinging too far the other way. In a small office where laptops discover the printer over mDNS and nothing else provides that service, these are the same packets, sent for the same reason, and they are the intended design. There is no vulnerability in the protocol to be patched. What differs between that office and the enterprise user segment is who else shares the link, how many hosts are asking for names nobody owns, and how automatically they ask. Classify the **environment**, not the protocol — and when writing the finding, say what the mechanism is rather than borrowing the name of a more famous one. ## The reusable habit When an attack resembles a famous one, check what the famous one actually requires. Cache poisoning requires a cache and a forged record. Neither is present. That check takes seconds and prevents a whole strand of misdirected work.