mDNS

Reading time: 10 minute Word count: 1924

Network mDNS DNS Multicast

On the same local network, a phone can see a TV, a computer can see a printer, and a speaker can be used for casting, even when there is no dedicated DNS server doing local name resolution for them. When a device first joins the network, it may not even know who it is supposed to ask. Still, it has to recognize names first so that service discovery has somewhere to land.

mDNS handles exactly that step. It does not copy the Internet DNS model into the LAN. Instead, it lets devices on the same local link resolve names directly by multicast, without a central recursive resolver, without manual registration, and without extra configuration.

mDNS is not “DNS turned into multicast”. It replaces central DNS with shared multicast question-and-answer and soft-state caching so devices can resolve names under zero-configuration conditions

Why It Appears

Classic DNS assumes a clear setup:

The endpoint knows which resolver to ask
The resolver knows which recursive chain to use
The domain and records are already registered in an authoritative system

But many local network environments do not satisfy those assumptions:

Home networks may not have anyone maintaining a local DNS zone
Temporary networks, hotspots, and meeting-room networks are not suitable for pre-registering every device
Newly joined devices need to be discoverable immediately without manual setup
Devices care about “who on this link is printer.local”, not about a public name reachable from the whole Internet

The common thread is simple: devices need a local autonomous name-resolution method, and it must be usable by default without first depending on a central node.

Keep the Boundary Clear

mDNS works in a very narrow boundary, and that narrowness is exactly what makes the model stable:

It only solves local-link name resolution
It mainly serves .local.-style local namespaces
It does not do cross-subnet recursive resolution
It is not a replacement for public Internet DNS

That means mDNS is really saying:

Devices on the same local link all listen on one well-known name-resolution channel;
whoever owns a name answers for it.

Compared with classic DNS, three things change:

Queries usually go to a multicast address instead of a preconfigured DNS server
The record owner answers directly instead of a central authority answering for it
Every device can be both a querier and a responder, while also maintaining local cache

The Most Common Main Path

If one computer in a LAN wants to access printer.local., the most common successful path looks like this:

The printer first confirms that the name is not already taken by someone else
The printer advertises its A, AAAA, or related records onto the local link via mDNS
When the computer needs printer.local., it sends a query to the mDNS multicast address
The printer sees the query and returns the records it owns
The computer caches the result by TTL and then connects to that address

You can think of it like this:

Querier -> Multicast: Who has printer.local.?
Owner   -> Multicast/Unicast: printer.local. is 192.168.1.23
Querier -> Cache result
Querier -> Connect to 192.168.1.23

The most important thing here is not what the packet looks like. It is that the role relationship changes:

In classic DNS, the endpoint asks a resolver
In mDNS, the endpoint asks the entire local link directly, and the device that actually owns the name answers

Why It Can Still Reuse the DNS Record Model

mDNS did not invent a whole new name system. It tried to reuse DNS names, record types, and caching semantics as much as possible. The benefits are obvious:

A, AAAA, PTR, SRV, and TXT do not need to be relearned from scratch
Applications and upper-layer service discovery can keep using the DNS data model
It is easier to connect to existing resolvers, cache logic, and debugging tools

But it only reused DNS’s “expression style”, not DNS’s “centralized question-and-answer path”. What changed is the division of responsibility:

DNS depends on authoritative servers and recursive resolvers
mDNS depends on devices on the local link announcing themselves

That is why mDNS looks like a DNS variant but has a completely different engineering meaning.

Why It Has to Rely on Multicast

When a device first joins a LAN, it often does not know:

Which machine provides local name resolution
Who owns a given name
Whether another device already took a candidate name

If everyone had to know a central node first, zero configuration would already be broken. Multicast provides the shared default entry point:

The querier does not know the owner, but can still send the question out
All potential owners can see the question at the same time
Name conflict detection, active announcement, and cache refresh can all use the same public channel

The cost is obvious too: each node may receive many packets that are irrelevant to it. So mDNS design always balances:

Accept some in-link redundant traffic to get zero-configuration autonomy
Use caching, response suppression, and record TTL to keep that traffic acceptable locally

Why Name Conflict Handling Is a Core Mechanism, Not a Side Detail

In classic DNS, names are usually assigned and managed in a central authoritative system. mDNS does not have that assumption. A device deciding to call itself printer.local. does not mean nobody else is already using that name.

So when a device comes online, it has to solve a more primitive problem first: is this name already taken?

The most important engineering flow is usually not “what do I call myself?” but:

Probe whether the candidate name already has an owner
If there is no conflict, announce ownership
If a conflict appears, choose a new name or rename and try again

If you skip this step, mDNS quickly degrades into “whoever replies first wins”, which is not stable. In LANs with printers, casting devices, and development boards joining automatically, this kind of conflict is not rare.

Why the Cache Must Be Soft State

mDNS results cannot be treated as permanent truth because local devices change much faster than Internet DNS authorities do:

Devices may go offline at any time
Wi-Fi roaming, sleep, and wake cycles change reachability very often
A rebooted device may reannounce its records
The owner may rename itself after a conflict

So mDNS, like DNS, has TTL, but here TTL behaves more like a local soft-state constraint:

The querier caches records so it does not have to multicast every time
Once records expire, they must be confirmed again
When devices go offline or rename themselves, stale caches should eventually die off naturally

That is why, during troubleshooting, it is not enough to ask “did I once resolve it?” You need to know whether the answer is still fresh and who last announced it.

Why It Is Not the Same as Service Discovery

mDNS often shows up together with AirPlay, printer discovery, and smart-home discovery, so people naturally start treating it as a synonym for “service discovery”. That is not quite right.

mDNS solves:

How names and records are found on the local link

DNS-SD solves:

How a service instance is organized through PTR, SRV, and TXT records
How a device expresses “there is an _ipp._tcp print service here” or “there is an _airplay._tcp service here”

They appear together because DNS-SD is a very good fit for running over mDNS’s local zero-configuration resolution path. But the boundary still matters:

mDNS is the local name-resolution mechanism that carries and answers these records
DNS-SD is the organization method that uses DNS record structure to describe services

If you blur that boundary, later troubleshooting becomes distorted. Many failures are really:

mDNS queries not getting responses
Or the DNS-SD service records themselves not being published correctly

Those are different problems.

What Tradeoff It Actually Brings

It only lives safely on the local link

The most important assumption in mDNS is that it lives on the local link. Typical queries go to a local-link multicast address, and the design does not intend to recursively spread the query across Layer 3.

That means:

Devices in different subnets do not automatically see each other’s mDNS names
VLANs, guest networks, and enterprise isolation networks naturally cut off this kind of discovery
If you want cross-subnet discovery, you usually need an extra gateway proxy, reflector, or other centralized mechanism

If you think of mDNS as a “lightweight DNS replacement”, you will immediately find that assumption broken as soon as you cross the Layer 3 boundary.

Multicast noise is real

In a small home network, mDNS overhead is usually not obvious. In dense device environments, complicated wireless environments, or low-power links, multicast traffic becomes visible:

Every node has to receive some queries passively
New device join, wake-up, and rename events trigger probes and announcements
When there are many services, attached records also increase packet volume

So the problem with mDNS is usually not “is a single query slow?” It is “when the device count grows, can this shared channel still stay quiet enough?”

The result depends heavily on implementation quality

The specification gives the basic semantics, but real-world experience depends a lot on whether the implementation gets the details right:

Does it probe for conflicts correctly
Does it use caching and TTL reasonably
Does it suppress unnecessary duplicate responses
Does it reannounce correctly after network changes, sleep, or wake

These differences do not change mDNS’s nature, but they do directly affect why it sometimes works and sometimes suddenly disappears.

What to Look At First in Packet Capture and Troubleshooting

Do not start by staring at the field list. A more useful order is below.

First check whether the problem was cut off by a Layer 3 boundary

Confirm whether the two sides are really on the same local link or the same Layer 2 broadcast domain. If the traffic already crosses a subnet or VLAN, mDNS is not supposed to be naturally visible by default.

Then check whether the name owner announced and maintained the record correctly

Focus on:

Whether the device probed on join
Whether a conflict caused it to rename itself
Whether there were periodic announcements or reannouncements
Whether the record TTL was reasonable

Many “cannot find the device” cases are not caused by the querier failing to ask. The owner simply never stabilized its own presence.

Finally check whether the query got the expected answer

Here the key is not to memorize fields, but to judge:

Was the query sent to the right name or service type
Who answered
Was this an address-record issue or a service-record issue
Was there no response at all, or only a stale answer in cache

That is how you separate “name-resolution failure” from “service-publication failure”.

What Engineering Should Actually Think About mDNS Today

Do not think of mDNS as a small DNS server. It is a local-link shared resolution mechanism
Do not confuse it with DNS-SD. mDNS handles the local resolution path; DNS-SD handles service-description structure
Do not forget its boundary is the local link. Cross-subnet discovery is not its default job
Do not underestimate name conflicts and soft-state caching. Those two things decide whether it can run stably in zero-configuration environments
Do not blame everything on “the network is bad”. Many symptoms are actually caused by implementations not handling probing, announcement, and reannouncement well