DNS-Based Multicast Stream Discovery

Several documents describe locally-scoped or administratively-scoped allocation of multicast addresses. Some examples of this include:

These documents do not specify a mechanism for how these multicast streams should be advertised or discovered. This document specifies an application of DNS-Based Service Discovery (DNS-SD, ) for advertisement and discovery of multicast streams.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DNS-SD uses PTR, SRV, and TXT records to describe a service. DNS-MSD also makes use of these records to describe a multicast stream, but makes a few modifications to the method described in . First, DNS-MSD uses a new "mcast.arpa." special use domain in all records to indicate that the advertised service is a multicast stream. The second label in the <Service> portion of a Service Instance Name MUST be "_udp". The port advertised in the SRV record has a restriction not seen with unicast services. Unicast services can dynamically allocate a free port for the service. Multicast streams cannot use a dynamic port because there is no guarantee that applications on all clients can bind to the dynamic port. If all devices on the network are purpose-built for the application, then multicast streams may use a pre-determined port in the dynamic range. Otherwise, multicast streams should use a port registered with IANA. In either case, the chosen port is advertised in the SRV record. The hostname advertised in the SRV, A, and AAAA records is a combination of the <Instance> portion of the Service Instance Name, the hostname of the stream's origin, and the "mcast.arpa." special use domain name. Finally, the address advertised in A and AAAA records is the chosen multicast address. The "in-addr.arpa." and "ip6.arpa." records advertised for reverse lookup also reflect the chosen multicast address.

When used with Mulicast DNS , DNS-MSD can provide a zero-configuration mechanism for advertising and discovering multicast streams. Nothing in DNS-MSD restricts its usage to link-local scope multicast addresses. If Multicast DNS is needed to provide zero-configuration address advertisement in other scopes, then the recommendation is to consider using it with larger-scoped addresses (see and note in ).

An example host has an Ethernet MAC address of 00-00-5E-00-53-00. This is used to create IPv6 link local address fe80::200:5eff:fe00:5300. It creates a link-scoped IPv6 multicast address ff32:ff:200:5eff:fe00:5300:aabb:ccdd to transmit with. Its hostname is "example", the service name is "_heartbeat._udp", service instance is "instance", and by pre-agreement all hosts on the network reserve port 62000 for this protocol. It has no additional data to include in a TXT record. The following DNS records are created: _heartbeat._udp 4500 IN PTR instance._heartbeat._udp.mcast.arpa. instance._heartbeat._udp.mcast.arpa. \ 120 IN SRV 0 0 62000 instance.example.mcast.arpa. instance._heartbeat._udp.mcast.arpa. 4500 IN TXT "" instance.example.mcast.arpa. \ 120 IN AAAA ff32:ff:200:5eff:fe00:5300:aabb:ccdd d.d.c.c.b.b.a.a.0.0.3.5.0.0.e.f. \ f.f.e.5.0.0.2.0.f.f.0.0.2.3.f.f. \ ip6.arpa. 120 PTR instance.example.mcast.arpa. Note that the backslash ('\') denotes a line that was divided for publication.

The special-use domain "mcast.arpa" should be registered in the "Special-Use Domain Names" registry .

Domain name reservation considerations for "mcast.arpa." as required by :

Users will not use the "mcast.arpa." domain directly.
Applications SHOULD recognize the "mcast.arpa." domain and reject any use in a unicast context.
Name resolution APIs and libraries SHOULD resolve the "mcast.arpa." domain to the multicast address that carries the service's data.
Caching DNS servers SHOULD NOT recognize the "mcast.arpa." domain as special.
Authoritative DNS servers SHOULD NOT recognize the "mcast.arpa." domain as special.
DNS server operators SHOULD be aware of the "mcast.arpa." domain's use in resolving multicast services.
DNS registries/registrars MUST NOT allow the "mcast.arpa." domain to be registered to any person or entity.

This document does not have any additional security notes beyond what is described in .

Special thanks to the National Marine Electronics Association for their contributions in developing marine industry standards and their support for this research.