mDNS candidates and local IP exposure

Run a WebRTC leak test today and you will probably see entries like 4a7c3e91-2b8d-4f1a-9c6e-8d2f1b3a5c7e.local. That is a randomly generated hostname standing in for your local network address, and it is the browser protecting you rather than leaking anything.

The leak it replaced

WebRTC has to discover every address a peer can be reached on, which includes addresses on your local network — 192.168.1.42, 10.0.0.7 and so on. Until about 2019 those were handed to any page that asked, with no permission prompt.

That was more useful to trackers than it sounds. A local address is not routable from outside, so it identifies nobody directly. But it contributes to a browser fingerprint, it reveals how many interfaces a machine has, and combined with the public address it distinguishes devices behind one connection.

What mDNS does instead

Multicast DNS, defined in RFC 6762, resolves names ending in .local by asking the local network directly rather than a DNS server. It is what makes printer.local work without any configuration.

Browsers now generate a random .local name for each local address, register it on the local network, and publish that name instead of the address. A genuine peer on the same network can resolve it and connect. A tracking script on a web page gets a random string that means nothing anywhere else.

The names are regenerated per origin and per session, so two sites cannot correlate them and neither can the same site across visits.

Reading a leak test result

What you see	Meaning
something.local	Protection working. Not a finding.
192.168.x.x, 10.x.x.x, 172.16–31.x.x	Local address exposed. Minor.
The VPN server's public address	Expected.
A public address that is not the VPN's	The real finding.

The WebRTC leak test labels these, and the distinction is worth internalising because a great many older guides describe .local entries as a leak. They were written before the mitigation existed.

Why a bare local address still appears sometimes

• Older browsers, which never got the change.
• Some enterprise policies disable mDNS candidates, because they break certain internal conferencing setups.
• Non-browser WebRTC implementations, such as an Electron app or a native library, which may not implement the substitution.
• Firefox with the feature disabled in about:config.

If you see one, it is minor. Addresses in those ranges exist on millions of home networks at once and cannot be routed to from outside.

What it does not protect

The public address a STUN server reports is not substituted, because peer connections genuinely need it. That is the entry a VPN user should care about, and it is the one that reveals a real address when the tunnel does not cover WebRTC.

Confirm what the world sees with what is my IP and compare it with what the WebRTC test reports. Those two agreeing is the outcome you want; a mismatch means the browser is describing an interface the tunnel does not cover.

The design lesson

This is one of the better privacy fixes the web platform has shipped, because it solved the problem without breaking the feature. Peers on the same network can still find each other; pages cannot learn anything.

That is worth noting given how often the alternative is offered — disable the API, break video calls, call it a privacy setting. The mDNS substitution is what a real mitigation looks like, and it is why the remaining WebRTC exposure is now one address rather than a list.

Why the local address mattered at all

Three uses, all of which the substitution removes.

Fingerprinting. A local address like 192.168.86.31 is not unique, but the subnet a network uses is a small signal, and the number of interfaces a machine reports is another. Combined with everything else a browser exposes, it narrowed a fingerprint.

Device counting. Two visits from the same public address with different local addresses are two devices on one connection. That distinction is useful to anyone building household-level profiles.

Local network scanning. A page that learns your subnet can probe it, which was used to fingerprint routers and to reach devices with weak local authentication. Browsers have since added separate protections against private network requests, but knowing the subnet was the first step.

The trade-offs the browsers accepted

mDNS is not free. Registering a name broadcasts it on the local network, so anyone on the same network sees the announcement — which is fine, because they already see your address by being on the same network.

It also adds a small delay to establishing a peer connection, because the name has to be registered and then resolved. That is measured in milliseconds and is invisible in use.

Some enterprise conferencing setups broke, because they relied on candidates containing literal addresses. Those deployments disable the feature by policy, which is why a corporate laptop may show bare local addresses where a personal one does not.