Why Chrome cannot open a .local address, and Safari can

You put a machine on the office network so that people can reach it as something.local. Safari opens it. Chrome does not — and the error is not “server not found” but DNS_PROBE_FINISHED_NXDOMAIN, which means a DNS server actively answered “no such name.”

We hit this while installing our own AI server, and tracked the cause down on real hardware. Here is what we found.

Two suspects that turned out to be innocent

The local network permission. macOS asks an app for permission before it may discover devices on the same network. Chrome already had it. And if permission were the problem you would get a connection error, not “this name does not exist.”

Secure DNS (DoH) in the browser. With it enabled, lookups go to an encrypted resolver instead of the system one. This was our main suspect at first. Turning it off changed nothing.

So we asked three different resolvers

We stopped guessing and queried the name directly, changing only who we asked.

The pattern is unambiguous: every ordinary DNS server says the name does not exist, and only the machine itself can answer for it.

The real cause: where the browser asks

.local is not a name you look up in ordinary DNS. It is reserved for multicast DNS (RFC 6762), in which devices on the same network segment answer for themselves. Queries go out as multicast, and routers play no part in it.

• Safari goes through the operating system’s resolver (Bonjour on macOS), so the OS resolves .local over mDNS → it opens.
• Chrome (Chromium-based) has its own resolver and bypasses the OS to query ordinary DNS → and ordinary DNS, by definition, never holds a .local record. Whichever resolver it reaches, the answer is “no such name.”

This is not a misconfiguration, then. It is a difference in design: one browser delegates name resolution to the OS, the other does it itself. Neither is wrong, but the consequence lands on whoever ships the device.

There is nothing the device can do about it

There are only two ways to publish a name on a network: mDNS, or a DNS server. mDNS can serve .local and nothing else, and the Windows-oriented alternatives (LLMNR, NetBIOS) do nothing on macOS. However hard the device tries, it cannot reach a browser that insists on asking ordinary DNS.

Worth adding: mDNS cannot cross an L3 VPN either (L2TP/IPsec, WireGuard and the like), because multicast does not leave the local segment. Reaching a device by name from outside the office is not something that can be made to work.

What we changed

Our AI server shows the address you should connect to on a small display on the unit itself. The standard procedure is now simply to open the address shown on that display. It depends on no name at all, so there is nothing to get stuck on.

We had in fact built a mechanism for issuing a per-customer name from our side. Then we decided not to use it, for two reasons.

• It would make the entrance to a customer's own server depend on a name that we hand out. A customer must never be locked out of their own server because something went wrong on our side.
• Nobody really wants another company's name attached to their own server.

The hook for using a name is still there. Register your own domain in your own DNS and the address line on the display becomes that name, falling back to the IP automatically when the name will not resolve. A name is something you bring yourself, if you want one.

While the name was the headline, people typed exactly what the display told them and still could not get in. That is the worst kind of failure, because the product itself was giving the wrong instruction. Whether a name resolves depends on the visitor’s device and its settings — something a vendor does not control — so a product must not assume one.

If you are hitting this

• When .local will not open, use the IP address. That is the fastest way through.
• Getting different results in different browsers is not a configuration mistake. If Safari opens it and Chrome does not, this is almost certainly why.
• If you want a permanent name for a machine on your network, register it in your own DNS rather than relying on .local.
• Across subnets, or over a VPN, .local simply does not apply.

Giving a machine a friendly name feels like a kindness. Printing an address that does not open is not. Keep the name as a convenience, and let the address that always works be the one you put first.

← Back to Technical Notes　All posts