mDNS is often described as DNS without configuration. Ordinary DNS needs an authority and records; mDNS makes a name such as printer.local work without configuring either first.
It does that by narrowing the scope of the problem. Every participant on one local link can contribute to the answer. That makes zero-configuration discovery work well, but gives it no basis for resolving names across subnets, enforcing identity, or presenting an authoritative inventory.
What problem does mDNS solve?
Conventional DNS assumes that somebody owns a zone and runs an authoritative server for it. That is the right arrangement when a name needs to work across networks and survive independently of the machines using it. It is unnecessary friction when a laptop wants to find a printer on a home network, or a device wants to offer a service in a room with no managed DNS at all.
Multicast DNS keeps the DNS message format and record types, but sends queries and responses to a multicast group on UDP port 5353. For the familiar .local. domain, the IPv4 address is 224.0.0.251; IPv6 uses FF02::FB. Both are link-local multicast addresses. Routers do not carry that traffic as ordinary routed DNS traffic, so an mDNS name is meaningful only on the link that originated it. A laptop can ask, "Who has printer.local?" Every interested host on the local link can hear the question, and the host that owns the record can answer. There is no registrar, zone transfer, or central server to configure first.
How can a name work without a DNS server?
It works because the peers cooperate. Before a host claims a record that should be unique, it probes the link to see whether another responder already claims it. It then announces the record and continues to watch for conflicting answers. If two uncoordinated machines want the same name, the protocol gives them a way to detect the collision and choose again. It does not prove either machine has a greater right to the name.
The records are cached, with TTLs that tell receivers how long they may treat a result as current. A device can also send a cache-flush update or a goodbye record with a zero TTL when its information changes. Devices can arrive, disappear, wake from sleep, and reappear without an operator updating a record set.
mDNS relies on cooperation. The specification says that conflict resolution assumes cooperating participants and recommends a stronger mechanism, such as DNSSEC or IPsec signatures, when hosts on the same physical link may be antagonistic. Removing the server removes setup work and the arbiter that would settle a dispute.
Why do printers and local developer tools appear automatically?
DNS-Based Service Discovery, or DNS-SD, describes what a device offers. A service advertises a type, an instance name, and the information needed to connect. A browser first obtains PTR records for a service type such as _ipp._tcp.local.. Those records name the available instances. It then resolves an instance's SRV record for the target host and port, its TXT record for service-specific metadata, and the address records for the target host.
The user sees Office Printer, not an IP address and an undocumented port. A local development tool can advertise a temporary endpoint without requiring a hosts-file edit or test registry. The DNS-SD specification defines the PTR, SRV, and TXT roles; mDNS provides one way to distribute those records on a local link.
DNS-SD is not synonymous with mDNS. The same record model can live in managed unicast DNS, where an organization can choose the domain, authority, access controls, and replication model. mDNS is the zero-configuration local transport choice.
What does zero configuration cost?
Multicast turns a lookup into shared work. A conventional DNS request normally goes to one resolver. An mDNS query is visible to every participant listening to the multicast group, and multicast responses are visible to them too. That shared visibility lets other hosts populate their caches and notice conflicts, but it also means discovery traffic consumes a shared local resource.
The protocol spends considerable effort containing that cost. Clients include known answers in later queries so responders can suppress redundant replies. Responders randomize response timing so identical answers do not all arrive at once. Queries back off, cache maintenance runs only while something has an active interest, and responders rate-limit record advertisements. Without known-answer suppression, the standard warns, traffic can become unacceptable.
Those mechanisms are effective on the small, mostly cooperative links mDNS was designed for. They do not create a central inventory, make Wi-Fi multicast reliable under load, or explain why one client saw a service and another did not. They trade configuration for distributed coordination. On a desk, in a lab, at home, or on a small device network, that trade is usually sensible. It becomes less attractive as the broadcast domain and device count grow.
Where is the security boundary?
There is no authentication in the basic act of an mDNS responder saying, "I am this name" or "this service is here." Anyone who can participate in the local link can observe the service advertisements, answer a query, or interfere with the cooperative naming process. The protocol has source-address checks to keep link-local answers local, but that is not a substitute for deciding which peers are trusted.
mDNS fits where discovery information can be public to the local link and the connection itself still performs real authentication and authorization. A printer's availability, a developer tool's ephemeral endpoint, or a device-control service on a trusted LAN can fit that model. A service whose existence is sensitive, whose client must prove identity before selection, or whose endpoint changes across multiple network segments needs a stronger control plane.
Forwarding mDNS with a reflector does not remove this boundary. It deliberately extends the link-like audience to another network. Sometimes that is the right operational choice, but it must be treated as an expansion of the discovery and trust domain, not as a free upgrade to managed service discovery.
When is mDNS no longer sufficient?
Use mDNS when the local link is the scope of the system. It fits consumer devices, printers, media endpoints, local peer discovery, temporary development environments, and a small lab where setting up a registry costs more than the multicast traffic it avoids.
It is insufficient when a name must resolve consistently from another subnet, over a VPN, in a second site, or after a device has left the building. The same applies when discovery needs access policy, auditability, health-aware routing, versioned metadata, or a clear owner for every advertised endpoint. Use unicast DNS and an explicit registry or control plane appropriate to the system. DNS-SD records can still be useful; the multicast transport is the part that no longer fits.
Previous: The Operational Reality
Next: Least Privilege Is an Operational Decision
The one-line version
mDNS replaces central DNS authority with a cooperative local link; use another discovery system when a name must mean more than that.