[dnssd] Re: [DNSOP] dnssd request for Assignment in the Underscored and Globally Scoped DNS Node Names

[Esko Dijk <[e-mail]>]

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 <paul=[e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> _______________________________________________
> dnssd mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]