When an mDNS client needs to resolve a host name, it sends an IP multicast query message. The message asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address.
By default, mDNS only and exclusively resolves host names ending with the .local top-level domain. This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that violate the zero-configuration goal.
Ok, but what does this mean?
With a simple explanation we can say that multicasting is normally limited to the subnet the device sending the multicast is in instead mDNS echoes the multicast to other subnets.
For example: if you have a Chromecast on a different subnet or VLAN (ex. IoT LAN), without mDNS your devices on the corporate network would not be able to detect it.
So, mDNS can be very useful to create firewall rules for IoT devices.
In this case we are going to connect two different network: the corporate network and the IoT one.
So, we have created two network: LAN (corporate) and IOT. On the LAN there are your personal and trusted devices such computers, phones. On the IoT network we have put all the smart things such Chromecast, Amazon Echo, Google home but also miscellaneus stuff connected to the internet.
At this point