MicrosoftAndrewRobinson I don't know about Windows specifically but for BSD sockets in general only one process is allowed to bind to a given port unless the SO_REUSEADDR flag is used (or the slightly different SO_REUSEADDR, where available). When you do have multiple sockets bound to a port, UDP multicasts/broadcasts are delivered to all eligible sockets, while unicasts are delivered to a single socket but which one is afaik implementation dependent and also depends on which flag you're using, e.g. on linux SO_REUSEPORT (but not SO_REUSEADDR) will distribute packets across the sockets for load balancing. For connected UDP sockets packets are matched on source ip and port in addition to destination ip and port. I have no clue what happens if an inbound packet matches both connected and non-connected sockets.
All this is mostly irrelevant for mDNS since normally you don't get unicasts sent to port 5353. The main caveat is that if an mDNS implementation that binds to port 5353 (i.e. advertiser or full stack) sets SO_REUSEADDR in order to coexist with other mDNS stacks on the same host then it should:
1. Enable the IP_MULTICAST_LOOP socket option to ensure it sees multicasts sent by other mDNS implementations on the same host.
2. Refrain from sending queries with the QU flag ("unicast response requested") set, since unicast responses cannot be delivered reliably. This is not really a problem since use of QU is merely an optional optimization that can be used to avoid multicasts responses in some narrow cases like revalidating records after waking from sleep.
Legacy/dumb resolvers (which do one-shot resolving instead of implementing the full mDNS protocol with mandatory caching and cache coherency) are prohibited from binding to port 5353, they work exactly like normal DNS resolvers apart from sending their query to port 5353 of the appropriate multicast address, i.e. they bind to a random port and must not set SO_REUSEADDR, therefore the (unicast) responses they get can be unambiguously delivered.
