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]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
