What does mDNS mean? If you can search for the TV screen or the NAS name doesn't connect, all the home auto-discovery is managed by it

Last month, my cousin was typing \fnnas\ on the study computer media wanted to drag out a movie. After running the file explorer for half a minute, a message popped up: "Network path not found." He called me over to check, so I deleted the name and changed it to \\192.168.31.20\media, and it opened instantly. He asked if the NAS was broken, and I said no, it was you who called out the name but no one answered.

there's something called mDNS managing this matter behind the scenes. Why can the TV cast at home be able to find each other, why iPhones can find printers, and why Home Assistant can automatically discover more than forty devices—all because of its messages below. Today, I'll break this down and explain it clearly, because when it breaks down, it's especially confusing—the problem is always "IP works, name doesn't work," which is the same root cause as when I connected my TV directly to my NAS to watch movies and it crashed.

first separate the two methods for name lookup

I once wrote an article about DNS parsing , which was a "serious" name lookup: you ask 223.5.5.5, it runs layer by layer to an authoritative server for you, and finally changes the domain name to an IP and returns it to you. There's a dedicated server in the middle to take care of you. You're going to the household registration office, where the director has a window at hand.

mDNS is a different set. It has no server, or in other words each device in the network is itself a server . If your computer wants to know what IP your NAS is called, it won't ask anyone, just shouts directly across the entire LAN: "Who's called fnnas?" State the house number! NAS heard it and replied to itself: "I, 192.168.31.20."

call isn't just empty talk; there's a fixed routine: the packet is sent from UDP's port 5353 and sent to multicast address 224.0.0.251, which is equivalent to the group number for all residents in this building. Any device posted on this network can receive it. Responding to whoever's IP is the answer, the reply packet goes back to 5353. The protocol specifies TTL of 255, making it very clear—this package can only be transferred on this link, not outside.

so mDNS tubes have a dedicated suffix: .local. fnnas.local is a name recognized by mDNS, which looks very similar to a domain name but doesn't use the same DNS as the internet. Sometimes when I visit the NAS management page, I just type http://fnnas.local:5666 and it can open—it's translated by it.

Why can the living room be connected, but the bedroom can't be opened

mDNS The documentation calls its scope of function "local link." The four characters "local link" literally means: signals are only transmitted through this second-layer link; the router defaults to no external assistance. I wrote a few lines of Python on a test machine completely isolated from HomeNet, joined the 224.0.0.251 multicast group, and waited for a full eight minutes—not a single packet. It then sent four name queries to this address, including n100.local and _http._tcp.local, but got no response. No one was on the chain, so shouting hoarse was useless.

this explains two true stories from my family. First: I converted an old router into an AP and set up an IoT private network for smart devices. From that night on, the living room TV could no longer find the camera I had moved in—two networks, no one could cross the multiplex, and no one could hear anyone shouting. The second is even more hidden: a relative came to my house and connected to guest WiFi, tried to cast on their phone, but the living room TV was clearly on but couldn't find it. Visitor Network uses AP quarantine, and quarantine blocks this kind of warning. I've written about this in this AP quarantine .

so remember one account: regular DNS asks for names worldwide, mDNS only handles the names on this link. is separated by routers, VLANs, and isolating switches—it's the same as any place, and the call is cut off. Later, I used a managed switch to set up a VLAN for the surveillance, and the NAS could still be detected by the TV. That's because both are in the mainnet zone and weren't separated. To connect across regions, you need a dedicated mDNS reflector to redirect the message—no need for home use.

Who at home is actually relying on it for a living

I spent the night waiting on the main network with a packet detection tool. Port 5353 was bustling with activity, much more than I imagined:

these "_xxx._tcp" style names are another layer of stuff, called DNS-SD, which the service discovers and runs on mDNS. To put it plainly: not only can you shout "Who is fnnas?" but also "Who can cast screens" and "Who can print?" The device itself raises its hand. Apple's pipe is called Bonjour, while on Linux it's called Avahi. Different names refer to the same well.

there's another easily confused thing: the SSDP used for Android phone casting is a different multicast protocol (the 239.255.255.250 protocol), which I wrote about in the of multicast section. Both sets of agreements do the same work, each shouting their own channel. So if you can't find it during casting, it depends on whether both sides are on the same channel—luckily, most TVs listen to both ends.

Windows computers most prone to "name failure"

My cousin's Windows can't connect when typing the name, and the root cause is Microsoft's historical baggage. Windows has its own old way of recognizing names: first ask DNS, then mDNS, then LLMNR (port 5355 broadcast), and if that fails, dig up the old NetBIOS calendar (port 137). After four floors, use whichever floor is connected. Where is the

pitfall? Before the 1809 version of Win10, Windows simply didn't recognize .local and wouldn't listen to mDNS. On older systems, if you type \fnnas\, it would broadcast to NetBIOS to ask, and the NAS's Samba service happened to return to NetBIOS, so most of the time it was just okay. But once the SMB service shuts down NetBIOS (many new firmware shut down by default), or inserts something that doesn't forward broadcasts, the name dies—and old Windows simply didn't have mDNS as a solution.

My cousin's car is an old version of Win10 that hasn't been updated for years, and that's exactly what it is. There are two ways: one is to honestly use the IP, the other is to upgrade the system. After 1809, Windows natively recognizes the name ending in .local. If you type ping fnnas.local it works, it means mDNS is working. Note that it only parses and does not publish—others can find your Windows via mDNS, but you can't find it using the Windows machine name. This is Microsoft's implementation, frustrating but helpless.

names sometimes work and sometimes not. According to this order, the

mDNS fault is characterized by "mystical": it can be opened today but not tomorrow; living room or bedroom is not suitable. I pedaled a lot and built a fixed order, basically following it without detours:

• try switching IPs first. IP access is not the same name, but it's really a matter of the name layer, unrelated to network speed or signal. Don't restart the router.
• check if both sides are on the same web. Guest WiFi, IoT private networks, and the WiFi built on optical modems are all different links. Calling out is inherently unacceptable—this is design, not a fault.
• check the system version. Old Windows doesn't recognize .local, but on Apple and Android phones, Windows 10 1809 and later, Linux all have no issues.
• check if the group broadcast was blocked. Some routers have aggressive IGMP snooping, placing multicast within the switching chip to prevent flooding, so the terminal can't receive a single packet; The same applies to AP isolating switches. Refer to my article on AP isolation and troubleshooting methods.
• still not being ruled out, then don't argue with the name. For devices like NAS, which are fixed for years, tie a static IP to the router, so phones and computers can store IP access and get access once and for all.

my own compromise: phones and TVs are constantly changing, relying on automatic detection, while NAS and printers are fixed IPs that never move. Automatic discovery is convenient, but it's not as reliable as a fixed house number.

casually say it's safe, don't panic

mDNS It's a shouting system—anyone can answer, and anyone can eavesdrop. This is a huge hole in the enterprise intranet—someone can forge a response and trick you into taking your login credentials, so the company's computer system commonly blocks this path. The risk at home is much lower: if you can't get out of your home chain, outsiders can't respond. If you want to be serious, just don't put unfamiliar devices on the mainnet. The guest network not only prevents unauthorized access but also keeps these discovery protocols out of the door. This is my family VLAN idea.

to remind you of the technical background: mDNS runs on UDP, has no connection, and sends without concern, so it's light but also loses packets. In environments with heavy interference in the 2.4G band, name resolution occasionally times out, so just try again. It's completely different from TCP's retransmission mechanism. I wrote about the division of labor between this pair in my TCP and UDP .

finish with an overall order: If the name can't connect, first change the IP to confirm it's the name layer, then check the same different network segments, then check the device's age and multicast switch. If the device doesn't work, just stick to the IP. That time, my cousin ended up binding the NAS with a static address of 31.20, and since then, all the IP files stored in the study computer have been the same, and he never got angry about the name again.