The original intention of underscored labels was to distinguish service names from all other uses of DNS names. For example, RFC 2782 states "An underscore (-) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature." IOW, LDH labels. It's perhaps unfortunate that RFC 8552 chose to use underscored labels for a different purpose altogether, rather than choosing a different reserved character. Oh well...
Cheers, Kerry On Wed, Oct 7, 2026 at 12:01 PM Esko Dijk <esko.dijk= [email protected]> wrote: > Not sure if we touched this already in the thread: but the practical > implication of all this, if I understand correctly: > > 1. services to be used with DNS-SD are to be registered in the IANA > "Service Name and Transport Protocol Port Number Registry". The service > name is in there without underscore. When used in DNS-SD, it gets an > underscore - for example "meshcop" becomes "_meshcop._udp.<domain>". > > 2. service names like above 'meshcop' are (almost) never registered in > the IANA "Underscored and Globally Scoped DNS Node Names" registry. They > should just go into the registry under 1. With that, they can be used in > combination with _udp or _tcp. > > This fits with Paul's remark: > > > 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 ? > > This seems for sure a better place if it is just about "some new service > that can be accessed via DNS-SD, or mDNS". Whether locally or globally. > As long as it gets postfixed by either "._udp" or "._tcp". > > There might be reasons why some elements get into both registries: I see > "ldap" is an example of such entry. > > best regards > > Esko > > > On 10/3/26 00:12, Ted Lemon wrote: > > If you read the original SRV RFC, it says that all protocol labels are > followed by either _tcp or _udp, and that is why they are used for DNSSD as > well. The reason for this is that the TCP port namespace and the UDP port > namespace are separate namespaces, so without specifying the port namespace > in the label, the SRV record is actually ambiguous, since it itself does > not specify a transport type. > > > > This whole model is probably not ideal, but it's what we have. So in > this context, the fact that the protocol label precedes a transport label > does not mean that it therefore does not need to be registered: just the > opposite. With respect to SRV records, there _aren't_ any labels other than > _tcp and _udp that immediately precede the domain containing the service > name. The service type is always followed by one or the other. > > > >> On 2 Oct 2026, at 23:55, Paul Wouters <[email protected]> > wrote: > >> > >> On Fri, 2 Oct 2026, Stuart Cheshire wrote: > >> > >>>> Or if phrased differently, you wouldn't put DNS-SD entries in your > >>>> public forward DNS zone that is hosted on the internet. > >>> Absolutely you would, and people do. > >>> > >>> This is described in the O’Reilly book “Zero Configuration Networking: > The Definitive Guide” > >>> > >>> < > https://www.oreilly.com/library/view/zero-configuration-networking/0596101007/ > > > >>> > >>> For an example closer to home, consider the IETF itself. For many > years, IETF meetings provided a printer in the “terminal room”. The NOC > staff added DNS records to describe that printer. This made the printer > discoverable from any wired or wireless network in any of the IETF meeting > rooms, not just from the local Ethernet in the terminal room. A > step-by-step explanation of precisely how this worked is available here: > >>> > >>> < > https://datatracker.ietf.org/doc/html/draft-cheshire-dnssd-roadmap-03#appendix-A > > > >> Ahh, thank you for that clarification. But I still see in such an > example: > >> > >> term-printer._pdl-datastream._tcp.meeting.ietf.org. > srv > >> > >> It is still below _tcp, so I would argue that falls outside the scope of > >> the Underscored and Globally Scoped DNS Node Names, which only talks > >> about the most parental underscore domain registrations. > >> > >> It seems pdl-datastreama (without underscore) is registered in the > regular > >> ports and services registry, eg > >> > >> https://www.iana.org/assignments/service-names-port-numbers?search=9100 > >> > >> So this still leads me to believe that these entries below the protocol > >> identigier in dns-sd, do not belong in the Underscored and Globally > >> Scoped DNS Node Names Registry. > >> > >> If I am still getting this wrong, please do let me know. > >> > >> Paul > >> _______________________________________________ > >> DNSOP mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > _______________________________________________ > > dnssd mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > dnssd 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]
