I would think using a subnet mask of 255.255.255.255 would insulate my device from other devices on the local network, but I still receive all of their mDNS messages even though they should be on a different network segment due to the mask.
Asked
Active
Viewed 1,409 times
2 Answers
15
First – no grounds for such a plan to work. Consider that with "typical" subnet masks such as 255.255.255.0, you already receive out-of-subnet packets on a regular basis, from the whole Internet (e.g. from web servers that your browser is talking to). That's literally how the Internet works.
This also applies to multicast. Even though mDNS specifically is "link-local", IP multicast in general is routable – it was even designed to be possible to be carried across the entire Internet (see 'Mbone'), and today there are still ISPs that route multicast packets between customers. So even though your mDNS software might refuse to process out-of-subnet mDNS packets, there is no reason that it wouldn't be able to receive them.
Second – the subnet mask only informs your device where it can send packets. (It is effectively a shorthand for an 'on-link' or 'device' route towards the subnet.) It has nothing to do with receiving them, and it is completely internal to your device: the rest of the network doesn't actually know which netmask you have configured at all.
Packets within the local subnet are delivered not by IP address, but by MAC address. Ethernet switches don't particularly care about the destination IP address (nor the source IP) – it's normal to have packets on an Ethernet that are addressed to device A at the MAC level, but something completely different at IP level.
(Indeed that's how gateways (routers) are used: when you need to send a packet to superuser.com, it is addressed to superuser.com's IP address but your default gateway's MAC address. That's why there is ARP and that's why the 'Default gateway' field is necessary: it tells the OS which device's MAC address it should send "Internet" packets through.)
So if a packet is addressed to the special 'Broadcast' or 'Multicast' MAC addresses, the Ethernet switches will deliver it to all ports (or all subscribed ports) no matter its IP-level source or destination; likewise will Wi-Fi access points. And once the packet has been transmitted towards you, you have no choice but to receive it – the OS might refuse to process it, e.g. if firewall rules reject it, but it cannot refuse to receive it.
Generally packet capture tools (like Wireshark) get their input at an early stage, before any firewall filtering much less any other processing, so even unwanted packets will will show up in Wireshark no matter what.
The only way to reliably isolate hosts is therefore to do it at the level of your Ethernet switches/routers (i.e. "Layer 2 isolation"). Most commonly it is achieved either by creating VLANs on the Ethernet switch – one IP subnet per VLAN – if supported by your router; or doing the same with separate physical switches, which go into distinct ports on the router (that is, not switched ports like home routers have).
grawity
- 501,077
3
The "m" in "mDNS" stands for "multicast", and multicast packets are sent to special multicast addresses which are independent of any unicast IP address subnets.
IETF Zero Configuration Networking (ZeroConf), of which mDNS is a major component, was specifically designed to be unhindered by IP subnet mismatch problems, which is one of the reasons it uses multicast. You are meant to be able to use [m]DNS-SD to discover all ZeroConf-capable devices on your network even if they are misconfigured and have a subnet mismatch.
If you had to do some reconfiguration to fix a subnet mismatch in order to make Zero Configuration Networking work, then it wouldn't be living up to its name.
Spiff
- 110,156