skip to content

What does a client verify about the host that answers its LLMNR or NBT-NS query?

level: middleimportance: must knowfreq 60%

answer

  1. no authority exists to appeal to
  2. presence on the link, not an identity
  3. match the transaction, accept the answer
  4. the fallback fires only for names nobody owns
  5. winning the name is not yet exploitation

basics

~20 s

Nothing meaningful. LLMNR, NBT-NS and mDNS carry no authentication, no signature and no record of who owns a name, so the client accepts the first well-formed reply matching its query. Whoever answers fastest on the link owns the name.

solid answer

~50 s

The client checks that the reply matches the outstanding query's name and transaction, and that is the whole of it. There is no signature, no certificate, no ownership registry and no authority to appeal to: these protocols were built for cooperative small links and presume goodwill. Two consequences matter in an interview. First, the qualification to participate is **presence on the link, not an identity**: a vendor's installed appliance with standing network access and no account anywhere in the directory can answer every query it hears. There is no account to disable and no credential to steal. Second, the responder is usually racing nobody at all — the fallback fires precisely because DNS said the name does not exist, so no rightful owner is on the link to contest the reply. Answering wins a name; it is not yet exploitation. The client then opens the connection it always intended to open, to an address of the responder's choosing.

go deeper

for a junior

Know the headline: these protocols authenticate nothing, and the first well-formed reply is accepted. Be able to say that any device on the segment can send one.

for a middle

Explain exactly what is matched - name and transaction - and what does not exist to be matched. Be ready to say why the fallback firing implies no rightful owner is listening.

for a senior

Work through the cost model: participation needs link presence, not identity, so unmanaged third-party kit carries the same capability as a managed host. Separate winning the name from what follows.

for a principal

Own the scoping argument: the unit of exposure is the broadcast domain, not the account population, so who can plug into a segment becomes a governance question rather than a directory one.

## The verification, stated exactly When a Windows host receives an LLMNR response it checks that the transaction identifier and the queried name match a query it currently has outstanding, and that the packet parses. It then takes the address in the response and caches it briefly. NBT-NS is the same shape with older wire formats; mDNS is the same shape with `.local` names. What is **not** checked, and does not exist to be checked: - any signature or MAC over the response - any certificate or cryptographic identity of the responder - any cross-check with DNS, the directory, or the DHCP lease table - any registry of which host is entitled to which name - any authority that could arbitrate a dispute mDNS does define probing and conflict resolution so that two cooperating responders do not both claim `printer.local`. That machinery presumes goodwill: it lets honest participants avoid collisions, and it has no way to distinguish an owner from a liar. ## Why the race is usually unopposed The common mental image is a sprint between the attacker and the real owner of the name. That image is wrong, and understanding why is the point of this question. The link-local query only happens **after DNS has denied the name**. If the name existed in DNS, resolution would have finished there and no multicast would have left the host. So the names on this path are the ones nobody owns: typos, dead servers in stale shortcuts, `wpad`, decommissioned hostnames in old scripts. There is normally no rightful owner listening at all. A responder that answers indiscriminately does not have to be fast — it only has to be the sole answer. Where a genuine race exists it is against **other responders**, not against the name's owner. ## Presence, not identity This is the property that changes how you think about the segment. Every other claim-making mechanism in an enterprise has some notion of principal: an account, a machine object, a certificate, a lease. These protocols have none. The prerequisites for answering are: 1. a network interface on the segment, and 2. the ability to send a UDP packet That is all. The consequence is that the third-party kit nobody thinks of as a computer inherits exactly the same power as a domain-joined workstation: a vendor's installed appliance under a support contract, a managed print controller, a building-systems box, a contractor's laptop in a meeting-room port. None of them needs a domain account, so none of them shows up in any account-based reasoning about who can do what on the network. It also means the adversary's cost model is unusual. Most claims cost something to acquire and something to hold — a credential to phish, a position to maintain. Here the cost is a port on the segment, and the capability is passive: listen, and reply to everything. ## Answering is not exploitation A precise candidate separates two things: - **Winning the name.** The responder has convinced one host that a name maps to its address. Nothing has been broken, nothing has been forged, and the responder has not touched the target. - **What the client then does.** The client proceeds with whatever it was going to do with that name — it opens a session, fetches a file, requests a configuration. That step, and everything an operator can extract from it, is a separate technique with its own preconditions and its own defences. Holding that line matters in interviews because it explains why the same primitive is sometimes worthless and sometimes decisive. If the name was a typo in a one-off `dir` of a share, the responder has won a single inbound connection. If the name is one that many hosts ask for automatically and whose answer configures the client, the same win is worth far more. ## What that implies about scope Because participation requires only link presence, the unit of exposure is the **broadcast domain**, not the estate, the domain, or the account population. Two questions decide the risk on any given segment: who can plug something into it or associate with it, and what names its hosts ask for that DNS does not hold. Neither question is answered by looking at directory permissions.

  • If DNS already said the name does not exist, who is a rogue responder actually racing?
    Usually nobody. The fallback only fires for names DNS does not hold, so there is normally no rightful owner on the link to contest the reply. Any race that does occur is against other responders. A responder that answers everything wins by default rather than by speed.
  • Why does a vendor appliance with no domain account matter more here than a domain-joined workstation?
    Because these protocols have no accounts. The qualification is a network interface on the segment, so unmanaged third-party kit inherits the same name-claiming power as a managed host — and there is no account to disable, no credential to rotate and no directory permission that constrains it.
  • Does mDNS conflict detection stop a host answering for a name it does not own?
    No. mDNS probing and conflict resolution exist so cooperating responders avoid claiming the same name by accident. They are a politeness protocol between honest participants; nothing in them can tell an owner from a liar, and a responder is free to ignore them.
  • How is this different from a forged DHCP or ARP claim on the same segment?
    Those claim an address or the gateway position and put the claimant in the traffic path for everything. A name answer claims one name for one asking host at one moment, and only for names DNS has already denied. It is narrower, cheaper and needs no upkeep.

saying these in an interview costs you the question

  • Says the client validates the responder against DNS or the directory
  • Describes it as a race against the name's rightful owner
  • Assumes a responder needs a domain account or credentials
  • Claims mDNS conflict detection prevents false claims
  • Treats winning the name as the compromise itself

context

resolving links…