[mDNS] OpenScreenProtocol should not restrict DNS-SD to mDNS
DavidSchinazi opened this issue · 5 comments
The spec currently states:
Open Screen Protocol agents must discover one another using DNS-SD over mDNS. To do so, OSP agents must use the Service Name _openscreen._udp.local.
This limitation seems arbitrary and will prevent OSP from working in enterprise contexts. The non-mDNS-based DNS-SD design allows service discovery to work even across broadcast domains. In particular, it's common for enterprises to have their user-facing Wi-Fi on a separate broadcast domain from their ethernet-connected hardware (printers, TVs, etc.). That prevents mDNS from working but a system administrator can decide to setup DNS-SD to allow devices on the Wi-Fi to discover specific services on other parts of the network - this is mainly done for printers today, but OSP shouldn't artificially prevent itself from benefiting from this technology.
Thanks @DavidSchinazi for your feedback can you provide more background information of the "non-mDNS" approach you have in mind?
PS: I recommend to check the archive/mdns.md document which includes details about our investigation (@mfoltzgoogle FYI)
Hi @louaybassbouss! Thanks for the link to your analysis, I think it's very thorough and complete apart from the fact that it conflates mDNS and DNS-SD. mDNS (which is defined in RFC 6762) is a subset of DNS-SD (which is defined in RFC 6763). DNS-SD works over both mDNS and non-mDNS (i.e. regular unicast DNS). Going into a bit more detail, DNS-SD has a concept of domain which means where you are looking for a service. The domain local. is reserved as a special-use domain name: DNS-SD queries in the local. domain are sent over mDNS whereas queries for all other domains are set over regular unicast DNS. All of the properties that the Open Screen Protocol cares about are provided by DNS-SD, with mDNS being a subset.
To create a baseline for interop we need have a mandatory mechanism for agents to discover each other. We could expand the scope of the spec to also require supporting DNS-SD discovery over unicast DNS, but I think the managed DNS situation is more common in enterprise environments. In general, "zero-configuration" scenarios are the intended base case.
The eventual goal is for agents to have the freedom to advertise themselves using any number of additional mechanisms, including unicast DNS, cloud registries, Bluetooth, QR codes, NFC, etc. by providing a way to map the necessary metadata onto these sub-protocols. But it would be easiest to add unicast DNS to the mix, since we already have mapped the discovery metadata onto DNS records.
I think the simplest thing to do would be to keep mDNS mandatory, but add unicast DNS support as a MAY for agents that want to work in managed/non-multicast DNS environments. I'd also like to hear whether there is a standard way for services to publish themselves to local DNS servers which would make interop for unicast DNS implementations more likely.
That sounds reasonable to me. The current text prohibits non-mDNS DNS-SD and I think we can solve that by rephrasing it to say that OpenScreenProtocol uses DNS-SD in general and that the mDNS subset is mandatory to implement.
Closed by #283.