Most people learn DNS as a simple question-and-answer system. A client asks a recursive resolver for a name, and the resolver returns an address. In practice, operating systems do not rely on unicast DNS alone. Before a query ever reaches a recursive resolver, many systems attempt one or more forms of local name resolution.
This behavior surprises administrators because it looks like DNS traffic but does not follow DNS delegation, caching, or authority rules. Protocols like Multicast DNS (mDNS) and Link-Local Multicast Name Resolution (LLMNR) exist to solve problems that conventional DNS was never designed to handle.
Why Local Name Resolution Exists
Traditional DNS assumes a few things. There is a configured recursive resolver. Names are globally unique within a namespace. Authoritative servers exist somewhere reachable on the network. These assumptions break down on small or temporary networks where no DNS infrastructure is available.
Local name resolution protocols were created to let hosts discover each other without relying on a central server. The original use cases were ad hoc networks, home LANs, and early service discovery systems. A printer, a file share, or a media device needed to be reachable by name even if no DNS zone had been created for it.
mDNS and LLMNR solve this by moving resolution closer to the hosts themselves. Instead of asking a known resolver, a client asks the local network and waits to see if any host claims the name.
How Local Name Resolution Works
Local name resolution is driven almost entirely by the client. When an application requests a name, the operating system decides how to resolve it and in what order. That decision depends on the OS, its configuration, and sometimes the name itself.
In general terms, the process looks like this:
- The application passes a hostname to the OS resolver.
- The resolver applies local rules and suffix handling.
- One or more local resolution mechanisms may be tried.
- Only after those attempts does the query fall through to unicast DNS.
Unlike DNS, local resolution protocols do not involve recursion, delegation, or caching across the network. Each host independently answers for itself. If no host responds, the name simply fails or is passed to the next resolution method.
Multicast DNS (mDNS)
Multicast DNS is defined in RFC 6762 and is most commonly associated with the .local top-level domain. Instead of sending a query to a resolver, the client sends a multicast query to a well-known multicast address on the local link.
Every host on the local network receives the query. A host that believes it owns the requested name responds directly, usually via multicast as well. There is no central authority and no guarantee of uniqueness beyond cooperative behavior between hosts.
mDNS is tightly coupled with service discovery. Protocols like DNS-Based Service Discovery (DNS-SD) build on mDNS to advertise services such as printers or media servers. In many operating systems, this behavior is automatic and largely invisible to the user.
A key limitation of mDNS is scope. Packets are not routed beyond the local link. This is intentional. mDNS is designed for environments where all participants are on the same broadcast domain.
corp.local. Windows machines resolve internal names like fileserver.corp.local without issue because Windows queries the configured DNS server for .local names by default. When macOS laptops are introduced, users on those machines cannot reach any internal resource by name. macOS treats .local as a reserved mDNS namespace and sends queries for fileserver.corp.local via multicast instead of to the DNS server. No host on the local link responds via mDNS, so the lookup fails silently. The fix typically involves either migrating the Active Directory domain to a non-.local suffix or configuring macOS DNS resolution overrides, both of which require significant effort in an established environment.
Link-Local Multicast Name Resolution (LLMNR)
LLMNR was developed primarily for Windows environments and is defined in RFC 4795. Like mDNS, it uses multicast queries to discover hosts on the local network without a DNS server.
In most implementations, LLMNR is only attempted for single-label names, meaning names without dots. This heuristic reflects its original purpose: resolving short, unqualified hostnames on a local network rather than participating in hierarchical DNS naming.
The mechanics are similar but not identical. LLMNR supports both IPv4 and IPv6 multicast addresses and can operate over UDP or TCP. It does not reserve a specific top-level domain in the same way mDNS does. Instead, the decision to use LLMNR depends on the client resolver configuration and name characteristics.
In practice, LLMNR often appears as a fallback mechanism. If a name cannot be resolved via DNS and does not qualify for mDNS, a Windows system may attempt LLMNR before giving up.
LLMNR has seen reduced emphasis over time due to security concerns and the increasing availability of proper DNS infrastructure. Like mDNS, it is vulnerable to spoofing on local networks. Any host can respond to a query and claim ownership of a name, which can be abused to redirect traffic or intercept connections. For this reason, many enterprise environments disable LLMNR entirely.
filesrver instead of fileserver. The DNS server returns NXDOMAIN because no record exists for the misspelled name. Windows falls back to LLMNR and broadcasts the query to the local network. The attacker's machine responds, claiming to be the requested host. The victim's machine silently sends NTLM authentication credentials to the attacker, who can then relay or crack them offline. This is one of the most common findings in internal penetration tests and a primary reason many organizations now disable LLMNR via Group Policy.
Interaction With Conventional DNS
Local name resolution does not replace DNS. It precedes it.
When a hostname is resolved, the OS applies a resolution order. That order determines whether a query is sent via mDNS, LLMNR, unicast DNS, or some combination of the three. The exact sequence varies by operating system and configuration, but a few common patterns help make this concrete.
On macOS, names ending in .local are typically resolved using mDNS first. These queries never reach a configured recursive resolver. For non-.local names, the system usually falls through to unicast DNS.
On Windows systems, unicast DNS is generally attempted first. If the query fails and the name is single-label, the resolver may then attempt LLMNR before giving up. Older Windows environments may also attempt NetBIOS Name Service (NBNS) as an additional fallback.
This ordering explains why administrators sometimes see unexpected multicast traffic for names they believe should be resolved by DNS. From the client’s perspective, local resolution is simply part of the decision tree.
In Windows environments, administrators may also encounter NetBIOS Name Service traffic alongside LLMNR. NBNS predates both protocols and serves a similar purpose: resolving short hostnames on local networks. While it is outside the scope of this article, its presence in packet captures often reflects the same underlying fallback behavior.
Why This Matters
Understanding local name resolution helps explain confusing behaviors in real networks. A hostname that resolves on one machine but not another may be relying on multicast responses rather than DNS records. Packet captures may show DNS-format packets that never reach a resolver. The wire format is the same as standard DNS, but the queries are sent to multicast addresses on the local network rather than to a unicast recursive resolver.
From an operational standpoint, local name resolution introduces ambiguity. Multiple hosts can claim the same name. Responses are not authenticated. Resolution behavior depends on client settings that may differ across devices.
These protocols exist because they solve a real problem. They also introduce tradeoffs that become visible as networks grow more complex.
Summary
mDNS and LLMNR were created to allow name resolution on networks without DNS infrastructure. They operate by asking the local network rather than a central resolver. Modern operating systems use them as part of a broader resolution process that eventually falls back to unicast DNS.
They are not replacements for DNS, and they do not follow DNS authority or delegation rules. They are local, cooperative mechanisms that exist alongside DNS, not inside it.