mDNS in action with the home automation Matter protocol
Real life example of mDNS being used to find and add devices to a home automation network.
Matter is a secure communication protocol between smart home products and IoT devices that uses Multicast DNS (mDNS) to find and add devices (a description of mDNS). mDNS is used for either one of two functions, to join a new device to the Matter network, or to join an existing device to the Matter network. Matter enables:
- Smart homes: Integrates a variety of devices such as door and window sensors, motion sensors, and environmental controls from multiple manufacturers.
- Energy management: Reduces energy use with smart metering and light and HVAC control.
- Commercial building management: Enhances operations and maintenance in commercial properties through the use of access control devices, automated lighting, environmental sensors, and controls.
Within the Matter framework, devices create a network called a “Fabric.” This network is an ecosystem where each device, consisting of one or more “nodes,” shares information with others. The term “node” refers to the functional part of the device that interacts within the network, differing from the device itself, which is the physical hardware. The process of a node joining the Fabric allows the device to integrate into the broader network, enabling it to discover other devices and share functionalities. Central to this joining process is mDNS, which is crucial for device discovery and commissioning.
Understanding mDNS in Matter device discovery and commissioning
The goal of the mDNS messages is to help devices find each other and successfully communicate through services. Later I will introduce the analogy between mDNS and a city guidebook to illustrate the technique used by mDNS to share information about the services and the hosts running those services for device discovery and commissioning.
Figure 1 illustrates how mDNS facilitates device discovery and commissioning in Matter, highlighting the role of different mDNS service names: _matterc._udp, _matter._tcp, and _matterd._udp for various discovery methods.
These discovery methods are:
- Commissionable Node Discovery (Fig. 1A): This method introduces new, uncommissioned devices (known as Commissionees) to the network, allowing nodes not yet part of any Matter Fabric to announce their presence using the service name _matterc._udp. Commissioners then identify and integrate these nodes into the appropriate Fabric.
- Operational Discovery (Fig. 1B): After devices are part of the Fabric, Operational Discovery enables these nodes to locate each other and communicate effectively within the network using the service name _matter._tcp.
- Commissioner Discovery (Fig. 1C): This involves the identification and authentication of Commissioners — devices or applications authorized to add new nodes to the Fabric using the service name _matterd._udp. Commissioner discovery ensures that only trusted entities have the capability to make changes to the network.
I’ll now explore the mDNS details for the three discovery methods through the use of a city guidebook analogy (see Fig. 2). All of these methods share use of the DNS record types: PTR, SRV, AAAA, and TXT (introduced here).
A city guidebook lists various services such as restaurants, retail, and automotive, which correspond to the services in Matter’s mDNS message. Specific names of Matter service providers, like grocery stores or restaurant chains in a guidebook, are linked to their respective Matter services using PTR records. For example, we will soon see how Matter uses the PTR records to link the service _matterc._udp.local with the service instance 19CAC273B02ADDF2._matterc._udp.local. In both the Matter PTR record example and city guidebook analogy, the operational location of the service instances and service providers is not yet given.
With mDNS to link a service instance to its operational location SRV records are used which detail the host and port where the service is accessible — similar to how a guidebook would connect a restaurant name to its street address. At this stage for both situations we know details about the location but lack absolute coordinates. We lack the restaurant’s latitude and longitude and similarly lack the service’s IPv6 address. The service’s IPv6 address is provided by the AAAA records which is analogous to the latitude and longitude of a location in our guidebook analogy.
Lastly, just as a city guidebook might offer menus and operating hours for restaurants, the Matter mDNS utilizes TXT records to deliver additional information necessary for the commissioning process. These records enrich the details in the other DNS records, so users have all the necessary information to use a service.
The following section details the three discovery processes and assumes all devices are already active on the same IPv6 local network. Because all communication is over the local network the mDNS names will have a suffix of “.local”. So, for example, the service _matterc._udp will be referred to as _matterc._udp.local.
The gory details
Commissionable Node Discovery
Devices, known as Commissionees, utilize mDNS to broadcast their readiness to be commissioned, allowing them to be integrated into the Matter Fabric. These broadcasts detail the devices’ capabilities and the services they offer within the network. Such broadcasting ensures that Commissioners can effectively locate and add these devices to the Matter Fabric. As shown in Figure 3 the guidebook listing all service categories is titled “_services._dns-sd._udp.local,” which consists of multiple PTR records. Some of these PTR records link the collection of all services (_services._dns-sd._udp.local) to a specific service such as _matterc._udp.local. Other PTR records connect a service to a particular service instance, like 19CAC273B02ADDF2._matterc._udp.local, with the hexadecimal values “19CAC273B02ADDF2” serving as a 64-bit random identifier to ensure uniqueness and avoid conflicts with other devices broadcasting the same service.
Figure 3 also illustrates how the unique service instance name, 19CAC273B02ADDF2._matterc._udp.local, is associated with a specific hostname and port number where the service can be accessed. This association is done using an SRV record, which maps the service instance to the hostname 000C2936F1E30000.local and the port number 5540. The final steps in establishing a complete service discovery path include locating the IPv6 address associated with the hostname, accomplished via an AAAA record, and gathering configuration information about the service provided by the TXT record.
The reason an AAAA record is necessary in addition to an SRV record is that SRV records do not directly contain IP addresses but instead provide the hostname and port where a service can be accessed. The AAAA record is essential because it maps the hostname to an IPv6 address completing the link by specifying the actual network address where the service is located. This separation adds flexibility and efficiency in managing network resources. For instance, if a device changes its IP address but retains the same hostname, only the AAAA record needs to be updated, without altering the SRV record.
The TXT record provides configuration information in the form of text based key value pairs. The definitions for the keys “DN” and “CM” can be found in section “4.3 Discovery” in the Matter Specification file “23–27349–005_Matter-1.3-Core-Specification.pdf”.
Operational Discovery
Once devices are commissioned and become part of a Fabric, they continue to use mDNS to dynamically advertise their operational services and detect real-time changes in the network. This means that as devices change state or move within the network, other nodes can discover these changes in real-time through mDNS queries and responses. This dynamic discovery is essential for maintaining seamless interoperability and functionality across an evolving smart environment, ensuring that services such as device control, status updates, and automation scenarios are consistently accessible.
Figure 4 illustrates the Matter mDNS record information necessary for Operational Discovery. The service identified is matter._tcp.local, where “_tcp” is standard text from the DNS SRV specification [RFC 2782] and does not indicate that the protocol operates over TCP (it runs over UDP). In this figure, the Operational Discovery mDNS record, 8119342D78A87D8A-23802BDBA1A2B688._matter._tcp.local, includes a 64-bit compressed Fabric identifier and a 64-bit Node identifier assigned by the commissioner. This contrasts with the Commissionable Node Discovery shown in Figure 3, where the service instance, 19CAC273B02ADDF2._matterc._udp.local, features a 64-bit random identifier. The longer identifiers in Operational Discovery reflect the structured network roles and relationships within the Fabric.
Commissioner Discovery
In this commissioning phase, mDNS is used to identify and authenticate Commissioners within the network. Devices that wish to become Commissioners broadcast their intent via mDNS, announcing their services related to commissioning. Existing nodes and other Commissioners can then discover these announcements and, through subsequent communication, verify and authenticate the new Commissioner. This use of mDNS ensures that only authorized devices or applications can make administrative changes to the Fabric to maintain security and integrity.
Figure 5 illustrates the Matter mDNS record information transmitted by a Commissioner to a Commissionee to complete Commissioner Discovery. This utilizes the service _matterd._udp.local and mirrors the process used in Commissionable Node Discovery as depicted in Figure 3. The key difference is that in Commissioner Discovery, it is the Commissioner, not the Commissionee, that sends the mDNS messages, emphasizing the role reversal in administrative functions within the network.
Wrap up
The implementation of mDNS within the Matter protocol highlights its critical role in commissioning. mDNS is a decentralized and flexible approach to network management, perfect for local relationships of dynamic IoT and home automation devices. mDNS not only facilitates the discovery of services in a structured manner but also provides the flexibility to adapt to changes in service location, type, and configuration seamlessly.
In this article I assumed every device is on the IPv6 network, but what happens if that is not the case? Then we need to look at how mDNS messages transverse across network technologies. This is the subject of the next article which will investigate how mDNS packets navigate the bridge between Ethernet and the IEEE 802.15.4 protocol Thread.
References
- Multicast DNS [RFC 6762]
- DNS-SD DNS Based Service Discovery [RFC 6763]
- Matter 1.3 Specification
