Welcome to My Weird Prompts, episode three hundred and one. So Daniel sent us this one — he's been wrestling with local network discovery, the kind where you type a name like "printer dot local" and it just works, until it doesn't. He's asking what's actually happening under the hood with services like Bonjour and mDNS, and specifically what you need to know if you're running a split DNS setup or your own resolver like AdGuard Home. Because that's where things get weird — the moment you take control of your DNS, local discovery can silently break. And it's one of those problems where everything looks fine until you try to print something.
The maddening thing is, the printer's right there. It's on. The network's fine. But your computer insists it doesn't exist. And the reason, when you trace it down, is that your carefully configured DNS resolver is doing exactly what you told it to do — and that's precisely the problem. The core technologies here are multicast DNS, defined in RFC 6762, and DNS Service Discovery, RFC 6763. Together they're what let devices announce themselves on a local network without anyone setting up a DNS server. Apple's implementation is Bonjour, Linux has Avahi, systemd-resolved handles it too, and Windows has its own flavor. They all speak the same protocol, but they all collide with custom resolvers in the same way.
Before we get to the collision, let's talk about what mDNS actually does. Because I think most people experience it as magic — you plug something in, a name appears, you use it. What's happening on the wire?
It's delightfully simple, and that's why it breaks in predictable ways. Regular DNS is unicast — your computer sends a query to a specific server at a specific IP address, and that server responds. mDNS is multicast — your computer shouts the question to a special address that every device on the local network is listening to, and whichever device owns that name shouts back. The multicast address is two twenty four dot zero dot zero dot two fifty one, port fifty three fifty three for IPv4, and ff zero two colon colon f b for IPv6. Any device can join that multicast group, and they all hear every query. When a device sees a query for its own name, it responds with a unicast reply directly to the asker. No central server, no configuration, no nothing.
It's like standing in a room and yelling "who's got the printer" instead of calling a specific person and asking them.
And just like yelling in a room, there are rules to keep it from becoming chaos. When a device joins the network, it probes first — it sends queries for its own proposed name, with a random delay between zero and two hundred fifty milliseconds, to see if anyone else is already using it. If someone responds, it picks a different name. That random delay is critical — without it, if twenty devices all joined at once and probed simultaneously, you'd get a multicast storm. The protocol designers thought about this.
A random delay feels almost too simple. But I guess that's the elegance of it — you don't need a coordinator if everyone just waits a slightly different amount of time.
Right, and it works surprisingly well in practice. The other clever bit is the cache flush mechanism. When a device is shutting down, it sends a goodbye packet with a TTL of zero, which tells every listener to flush that record from their cache immediately. Without that, you'd have stale entries sitting in caches, and devices would try to connect to things that aren't there anymore. It's a small detail, but it makes the whole system feel responsive — you unplug a printer and it disappears from the network within seconds.
Okay, so mDNS handles the name resolution part. But Daniel mentioned service discovery — the thing where you open your printer dialog and printers just show up without you typing anything. That's a separate layer, right?
That's DNS Service Discovery, DNS-SD, and it's built on top of mDNS. The way it works is beautifully recursive. Let's say you want to find printers on your network. Your computer sends a PTR query for underscore i p p dot underscore t c p dot local. That's the service type — IPP is the Internet Printing Protocol, TCP is the transport, and dot local is the domain. What comes back is a list of instance names — human-readable names for each printer advertising that service. For each one, you then query the SRV record, which gives you the actual hostname and port number. Then you query the TXT record, which gives you metadata — paper sizes supported, color or monochrome, whether it's got a scanner. Three layers of queries, all happening in milliseconds, and the user just sees a list of printers appear.
It's not just "here's a name, here's an IP." It's a whole directory service built out of DNS records, running on top of a multicast protocol that itself has no directory. That's kind of wild.
It's what makes zero-configuration networking actually useful. Without DNS-SD, mDNS just gives you name resolution — you'd still have to know the name of the printer. With DNS-SD, the printer advertises itself, and your computer discovers it without you knowing or caring what its hostname is. The same mechanism works for file sharing, screen mirroring, music streaming, home automation — anything where devices need to find each other without a central registry. When you open Spotify and see your living room speaker as an available target, that's DNS-SD at work.
Now we've got this elegant, decentralized system that works great on a flat home network with a standard router. Enter the custom DNS resolver.
The break happens because of a fundamental design assumption. mDNS assumes that queries for names ending in dot local will be sent to the multicast address, not to your configured DNS resolver. The dot local top-level domain is reserved by IANA specifically for this purpose — it's defined in RFC 6761 as a special-use domain name. Dot local is not supposed to exist in the global DNS. It's a link-local namespace. Your operating system is supposed to know this and route dot local queries to mDNS regardless of what DNS server you've configured.
That's the ideal world. In practice, what actually happens?
In practice, it depends on your operating system, your DNS configuration, and the phase of the moon. When you set up AdGuard Home or Pi-hole as your network's DNS resolver, you typically configure your router's DHCP server to hand out that resolver's IP address as the DNS server for all devices. Now when a device wants to resolve "printer dot local," it has a decision to make. Should it multicast that query, or should it send it to the configured resolver? The correct behavior, per the RFCs, is to multicast it. But not every operating system gets this right, and even when they do, the presence of a custom resolver can create edge cases.
Let's go through the operating systems. I'm guessing macOS handles this correctly, because Apple invented Bonjour.
Apple released Bonjour in two thousand two, and macOS has always treated dot local as a multicast-only domain. It will never send a dot local query to a unicast DNS server. So if you're on a Mac and you set up AdGuard Home, your dot local names continue to work because the queries never touch AdGuard Home at all. This is the correct behavior, and it's why Mac users are often confused when their non-Mac housemates start complaining that the printer disappeared.
Windows is the complicated one. Windows historically used LLMNR, Link-Local Multicast Name Resolution, which is Microsoft's own protocol, similar in concept but incompatible with mDNS. Windows ten and eleven do support mDNS natively, but it's not always enabled by default, and its behavior depends on how the network is configured. If you install Bonjour for Windows — which comes bundled with iTunes — you get full mDNS support. Without it, Windows will try LLMNR first, and may or may not fall back to mDNS depending on the version and settings. And critically, Windows does not have the same hard guarantee that macOS does about never sending dot local queries to the unicast resolver. In some configurations, Windows will send that query to AdGuard Home, and that's where the trouble starts.
Linux is the most configurable, which means it's also the most likely to be misconfigured. systemd-resolved, the default resolver on most modern Linux distributions, has a per-link MulticastDNS setting that can be set to yes, no, or resolve. If it's set to yes, it does full mDNS — it both responds to queries for its own hostname and resolves queries for other dot local names. If it's set to resolve, it only resolves queries, it doesn't respond. If it's set to no, mDNS is disabled entirely. The problem is that the default varies by distribution, and when you install something like AdGuard Home, you might change your DNS configuration in ways that bypass systemd-resolved entirely, or you might set AdGuard Home as the upstream for systemd-resolved, creating a chain where dot local queries go through multiple layers before they either get answered or fail.
Let's trace what actually happens when it fails. I've got AdGuard Home running. I type "my dash raspberry dash pi dot local" into my browser. Walk me through the failure.
Your browser asks the operating system to resolve that hostname. The operating system, depending on its configuration, may or may not recognize dot local as a multicast domain. If it doesn't — and this is the common failure case on Windows and some Linux setups — it sends a standard unicast DNS query to AdGuard Home. AdGuard Home receives a query for "my dash raspberry dash pi dot local." It looks in its cache — nothing. It looks in its rewrite rules — nothing. It looks in its blocklists — and here's where it gets interesting. Some blocklists include dot local as a suspicious TLD, because dot local is sometimes used in malware command-and-control. So AdGuard Home might just block it outright. If it doesn't block it, it forwards the query upstream to whatever DNS server you've configured — Cloudflare, Quad9, your ISP. That upstream server receives a query for a dot local domain, which by definition doesn't exist in the global DNS. It returns NXDOMAIN. AdGuard Home passes that NXDOMAIN back to your device. Your browser shows "server not found." The Raspberry Pi is sitting three feet away, perfectly reachable.
The entire time, the Raspberry Pi has been listening on two twenty four dot zero dot zero dot two fifty one, ready to respond, but nobody ever asked it.
Nobody ever multicasted the query. The query went unicast to a server that had no way to answer it. And here's the subtlety — even if AdGuard Home returns NXDOMAIN quickly, the operating system doesn't necessarily fall back to mDNS. It asked a DNS server, it got a definitive answer — "doesn't exist" — and as far as it's concerned, that's the end of the story. The multicast query never happens.
The fix isn't to make AdGuard Home answer dot local queries correctly. It's to make sure those queries never reach AdGuard Home in the first place.
And that's the misconception that trips up a lot of people. They think, oh, I'll just add a rewrite rule in AdGuard Home for my dot local devices. But that creates a different problem. Now AdGuard Home is returning a synthetic answer — it's saying "printer dot local is at one ninety two dot one sixty eight dot one dot fifty" — and the operating system accepts that answer and never multicasts. But the IP address might be stale, or the device might have changed its name, or AdGuard Home might not know about every service that device is advertising. You've replaced a dynamic, self-updating discovery system with a static, manually maintained hosts file. It works until it doesn't, and when it doesn't, it's harder to debug because the failure mode is subtle — the printer shows up but AirPrint doesn't work, or file sharing connects but drops randomly.
What's the actual right approach?
The cleanest fix for a flat network — no VLANs, everything on one subnet — is to add a conditional forwarding rule in AdGuard Home that sends all dot local queries to a non-existent IP address with a very short TTL. Something like forward dot local to one twenty seven dot zero dot zero dot one, which is localhost and will never respond. The query fails fast, and on most operating systems, a fast failure triggers the fallback to mDNS. You're not trying to answer the query — you're trying to get out of the way as quickly as possible so the real mDNS mechanism can do its job.
That feels like a hack. You're deliberately breaking DNS resolution so that the operating system falls back to a different protocol.
It is absolutely a hack. But it's a hack that acknowledges the architectural reality — mDNS and unicast DNS are different systems that happen to share a namespace, and the only way to make them coexist peacefully is to keep them from stepping on each other. The ideal solution would be for every operating system to handle dot local the way macOS does — never send it to the unicast resolver, period. But as long as we're living in a mixed-OS world, the fast-fail approach is the least bad option.
Alright, so that's the flat network case. But Daniel's the kind of person who probably has VLANs. What happens when you've got multiple subnets?
This is where it gets genuinely difficult. mDNS is link-local by design. Multicast packets don't cross subnet boundaries — routers don't forward them unless specifically configured to do so. If you've got your IoT devices on VLAN twenty and your main devices on VLAN ten, a multicast query sent on VLAN ten will never reach devices on VLAN twenty. The printer on VLAN twenty might as well be on a different continent as far as mDNS is concerned. This is actually a security feature — you don't want random multicast traffic leaking between subnets — but it breaks service discovery completely.
Your smart home hub on one VLAN can't see the devices it's supposed to control on another VLAN.
And this is a constant complaint in the AdGuard Home forums and the Home Assistant subreddit. Someone sets up a beautiful segmented network with IoT devices isolated on their own VLAN for security, and then nothing works. The Chromecast disappears from the casting menu. The printer is only visible from certain devices. The fix is an mDNS reflector or proxy — a piece of software that listens for mDNS traffic on multiple interfaces and repeats it across subnet boundaries.
What are the options there?
The most common one is Avahi, the Linux implementation of mDNS and DNS-SD. Avahi has a reflector mode — you set "enable dash reflector equals yes" in the configuration file, and it will forward mDNS packets between all the interfaces it's listening on. You run this on a device that has an interface on every VLAN — typically your router, if it's running Linux, or a small container connected to all the relevant subnets. There's also a tool called mdns-repeater, which is simpler — it literally just repeats mDNS packets from one interface to another. No caching, no intelligence, just packet forwarding.
You set up the reflector, and suddenly your HomePod on VLAN twenty can see the Homebridge on VLAN ten.
But now we've reintroduced the AdGuard Home collision problem, and it's worse because the traffic is crossing subnets. The HomePod on VLAN twenty sends an mDNS query. Avahi repeats it to VLAN ten, where the Homebridge responds. The response comes back through Avahi to VLAN twenty. But if AdGuard Home is also on VLAN twenty, and the HomePod is configured to use AdGuard Home as its DNS server, the HomePod might also send a unicast query for the same dot local name to AdGuard Home. AdGuard Home returns NXDOMAIN, and depending on the HomePod's operating system behavior, it might accept that NXDOMAIN and never process the mDNS response that arrived a few milliseconds later. The fix is the same conditional forwarding rule — forward dot local to a sinkhole address — but now you need to make sure it's applied consistently across all VLANs.
This is starting to sound like a network engineering job just to get a printer working.
Welcome to modern home networking. They just weren't designed to work together, and the people who use them together are a small enough niche that the integration pain hasn't been smoothed out by the vendors. Apple's solution is the HomeKit Hub — an Apple TV or HomePod that acts as a bridge between subnets for HomeKit devices. But that only works for HomeKit. If you're using non-Apple smart home gear, or if you just want your printer to work, you're on your own.
Let's talk about an alternative approach. Daniel mentioned split DNS, where you run your own internal domain — something like home dot example dot com — and use AdGuard Home to resolve it internally while everything else goes upstream. Does that avoid the dot local problem entirely?
Yes, and this is actually the direction the IETF has been nudging toward. RFC 8375 defines home dot arpa as a special-use domain specifically for home networks. The idea is that instead of relying on dot local for everything, you'd use home dot arpa for your internal DNS, and reserve dot local for true zero-configuration, transient device discovery. If you assign your Raspberry Pi the hostname "pi dot home dot arpa" and configure AdGuard Home with a rewrite rule that resolves it to its IP address, that query goes through normal unicast DNS, AdGuard Home answers it authoritatively, and there's no collision with mDNS because the domain isn't dot local. mDNS still works for discovering printers and Chromecasts — it's just that your static, always-on devices have proper DNS names in a domain you control.
You're separating the namespace. Dot local is for "I just plugged this in and don't want to configure anything." Home dot arpa is for "I set this up deliberately and want it to have a stable, resolvable name.
And this is the approach I'd recommend for anyone who's already running AdGuard Home or a similar resolver. If you control the hostname, don't use dot local. Use a real domain — even a fake one that only exists inside your network — and let AdGuard Home handle it with rewrite rules or conditional forwarding. Reserve dot local for the things you can't or don't want to configure manually — printers, smart speakers, streaming sticks, IoT sensors. Those devices use mDNS and DNS-SD to announce themselves, and they'll continue to work as long as you've got the dot local fast-fail rule in place and, if needed, an mDNS reflector for cross-VLAN traffic.
If you've already got a bunch of devices on dot local and you don't want to rename everything?
Then you live with the hacks. The conditional forwarding rule for dot local to a sinkhole IP. The mDNS reflector if you've got VLANs. And you accept that sometimes things will be a little flaky. The good news is that these problems are well-understood at this point — the AdGuard Home documentation covers the dot local collision, the Home Assistant community has extensive guides on mDNS across VLANs, and the tools are mature. It's not elegant, but it works.
You mentioned the IETF nudging toward home dot arpa. Is there actually momentum behind that, or is it one of those RFCs that nobody implements?
It's been slow. RFC 8375 was published in twenty eighteen, and adoption has been, let's say, deliberate. The big challenge is that dot local is deeply entrenched. Every printer, every smart speaker, every IoT gadget ships with dot local as its default domain. Changing that requires coordination across an entire industry. What's more interesting to me is the work on DNS-SD over unicast. RFC 6763 already has provisions for it — the idea is that instead of relying on multicast for service discovery, you'd register your services in a central DNS server, and clients would query that server using standard unicast DNS. This would eliminate the multicast limitation entirely — services would be discoverable across subnets without reflectors, and there'd be no collision with custom resolvers because everything would go through the same DNS infrastructure.
You'd have a local DNS server that knows about every service on your network, and devices query it just like they query any other DNS record.
And this is already how some enterprise networks handle service discovery — they use DNS-SD with unicast updates, where devices register their services with the central DNS server when they come online, and deregister when they leave. For home networks, the challenge is that you need a DNS server that supports dynamic updates, and you need devices that know how to register themselves. Most consumer devices today are built for multicast DNS-SD, not unicast. But as VLANs become more common in home networks — and they are, driven by security concerns around IoT — the pressure to support unicast service discovery will increase.
The long-term vision is that dot local becomes less important, not because it goes away, but because the things you actually care about move to a managed DNS infrastructure, and dot local is just the fallback for random transient devices.
That's the hope. And it aligns with the broader trend of home networks becoming more sophisticated. Ten years ago, the idea of running VLANs and custom DNS resolvers at home was a niche hobbyist thing. Now it's increasingly mainstream — people are buying routers that support VLANs out of the box, setting up Pi-hole or AdGuard Home for ad blocking and privacy, segmenting their IoT devices for security. The tools are getting better, but the protocols are still catching up to the use cases.
Alright, so let's bring this back to practical advice. Daniel's got AdGuard Home running. He's got some devices on dot local that have stopped working. He might have VLANs. What's his diagnostic checklist?
Step one: figure out if the dot local queries are even reaching AdGuard Home. Open the AdGuard Home query log and search for dot local. If you see queries for dot local domains, that's the problem — those queries should never have left the device. The fix is the conditional forwarding rule we talked about — forward dot local to one twenty seven dot zero dot zero dot one with a zero TTL. Step two: if you don't see dot local queries in AdGuard Home but things still aren't working, check whether mDNS is actually functioning on your network. On macOS, use dns-sd from the terminal. On Linux, use avahi-browse. On Windows, you might need to install Bonjour first. See if your devices show up when you browse for services. If they don't, mDNS itself might be broken — maybe your switch is filtering multicast, maybe the devices are on different VLANs.
If they are on different VLANs?
Step three: set up an mDNS reflector. If your router runs Linux, enable Avahi in reflector mode. If not, spin up a small container or a Raspberry Pi with interfaces on all VLANs and run mdns-repeater. Once the reflector is running, test service discovery from each VLAN. If it works but then breaks again when AdGuard Home is active, go back to step one and add the conditional forwarding rule. The key is to isolate the problems — mDNS not working at all is a different issue from mDNS working but being overridden by unicast DNS responses.
If all of that is working but you want something more robust long-term?
Then consider migrating your static devices to a proper internal domain. Pick something like home dot example dot com or home dot arpa, assign hostnames in AdGuard Home's DNS rewrite rules, and configure your devices to use those hostnames. Leave dot local for the zero-config stuff. It's more work upfront, but it eliminates an entire class of intermittent failures, and it makes your network easier to reason about. When something breaks, you know whether it's a DNS problem or an mDNS problem because the namespaces are cleanly separated.
There's something almost philosophical here about the tension between zero-configuration and control. mDNS is the ultimate zero-config protocol — you plug things in, they announce themselves, everything just works. But the moment you want control — VLANs, custom DNS, ad blocking — you're fighting against the very mechanisms that made things easy. You're trading convenience for security and privacy, and the protocols aren't designed to make that trade easy.
Zero-configuration networking was designed for a world where home networks were flat, simple, and trusted. You plugged everything into the same router, everyone was on the same subnet, and the biggest problem was making sure two printers didn't pick the same name. That world is gone. Modern home networks are complex, segmented, and increasingly adversarial — you don't trust your smart light bulbs, so you isolate them. You don't trust your ISP's DNS, so you run your own resolver. The protocols are slowly adapting, but there's a fundamental tension between "it should just work" and "it should work the way I configured it." And when those two goals collide, you get a printer that's online, reachable, and completely invisible.
What can you actually do about this? Here are three concrete fixes.
First, the dot local fast-fail. If dot local names stop working after setting up AdGuard Home, add a DNS rewrite rule for dot local pointing to a non-routable IP like one twenty seven dot zero dot zero dot one with a short TTL. This forces the operating system to fall back to mDNS quickly. Don't try to answer dot local queries with actual IP addresses — you'll just create a brittle, manually maintained shadow of what mDNS already does automatically.
Second, the VLAN problem. For multi-VLAN setups, run an mDNS reflector — Avahi, mdns-repeater, or a Docker container — on your router or a device that has interfaces on all VLANs. This is the only way to get cross-subnet service discovery. Without it, your devices are shouting into separate rooms and nobody can hear anyone else.
Third, consider migrating away from dot local for static devices. If you control the hostnames, use a real domain like home dot example dot com with split-DNS in AdGuard Home. Reserve dot local for truly zero-config, transient devices — printers, Chromecasts, smart speakers — that you can't or don't want to configure manually. This separation makes your network easier to debug and eliminates an entire class of intermittent failures.
Now: Hilbert's daily fun fact.
Hilbert: In the early Renaissance, European dyers on the Yamal Peninsula briefly adopted a theory that mammoth ivory, ground to powder and boiled with iron-rich bog water, would produce a permanent crimson dye. The theory lasted about forty years before traders realized the color came from the bog water itself and the ivory was doing nothing except making the process ruinously expensive.
I have so many questions about the economics of grinding up mammoth ivory for dye.
I have so many questions about why anyone on the Yamal Peninsula thought that was the variable to test.
Here's the open question I keep coming back to. As more home networks adopt VLANs and custom DNS resolvers, are we going to see a real shift away from dot local toward home dot arpa? Or will mDNS evolve to handle unicast resolution across subnets natively? The IETF is working on DNS-SD over unicast — RFC 6763 already supports it — which would let you register services in a central DNS server instead of relying on multicast. That could eliminate the dot local collision entirely. But adoption is slow, and dot local is deeply entrenched. It might take a decade of frustrated printer troubleshooting before the industry moves.
If you've debugged a dot local issue and have a story — especially if you found a creative fix we didn't cover — send it to us. We might feature it in a future episode. Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com.
Until next time.
