No, the expectation is that DNSSD works both with DNS and mDNS, and hence with domains other than .local. You can see this e.g. in RFC9665, which provides a way to deliver automatic DNS-SD within arbitrary DNS zones. RFC6763 specifically recommends RFC6335 as the source for how to register service types.
Bear in mind that although the content of RFC6762 and RFC6763 were finished around the year 2000 (plus or minus), they took a long time to get through the IETF publication process, and as a result, it was necessary to provide alternative resources until that happened. I believe that's what the www.dns-sd.org/servicetypes <https://www.dns-sd.org/servicetypes> page is about. > On 2 Oct 2026, at 19:43, Paul Wouters <[email protected]> wrote: > > > Dear DNS and DNS-SD experts :) > > The Designated Experts for the Underscored and Globally Scoped DNS Node > Names IANA Registry (RFC 8552) received a request to register a new > entry to be used with DNS-SD. See: > > https://www.iana.org/assignments/dns-parameters#underscored-globally-scoped-dns-node-names > https://www.rfc-editor.org/info/rfc8552/ > > > The question is, I believe that all DNS-SD entries are under a > parental underscore domain that is not global (eg _xmpp._tcp.local or > _printer._udp.local). As such, I believe entries meant for DNS-SD > are unrelated to the Underscored and Globally Scoped DNS Node > Names IANA Registry and should not (need not?) be registered there. > > Or if phrased differently, you wouldn't put DNS-SD entries in your > public forward DNS zone that is hosted on the internet. > > That said, there is obviously the possibility of DNS-SD names clashing > too, despite not being a globally scoped dns node name. But perhaps > the Service Name and Transport Protocol Port Number Registry > https://www.iana.org/assignments/service-names-port-numbers?search=dns > would be a better fit for such a registration ? > > I also found https://www.dns-sd.org/servicetypes.html but it seems to > be closed in favour of the service-name one. > > I am interested in hearing people's view on this. > > Paul > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
