mDNS: one of the smart home’s most important protocols
Multicast Domain Name System (mDNS) is a protocol that enables devices connected to a network to discover and resolve hostnames to IP addresses without needing a central DNS server.
mDNS is specified in IETF RFC 6762 and relies heavily on the standards already developed for DNS itself, including and especially the DNS Service Discovery (DNS-SD) standard. It was designed as a standardized replacement for the AppleTalk (also known as Bonjour) protocol in use at the time by many connected devices such as printers, IP cameras, etc.
mDNS is particularly useful for home networks where a central DNS server isn’t present and end devices don’t want to rely on the cloud for communication (e.g., a personal computer to a printer). Combined with DNS-SD, it is extremely important for smart home products and applications.
As such, home gateways often include built-in support for mDNS. Here are some of the most important things to pay attention to if you are responsible for testing mDNS on your home gateway and Wi-Fi router products.
Test basic mDNS query and response functionality
When testing mDNS, start with the basic query and response behavior of your device under test. mDNS protocol flow can be broken down as follows:
- An application or device needs to resolve a hostname to an IP address on the local network or visa-versa (reverse query).
- The application or device sends out a multicast DNS query for the hostname or IP it wants to resolve. In IPv4, this is sent to address 220.127.116.11 over port 5353 (address FF02::FB using IPv6).
- All hosts on the local network that have mDNS enabled listen for these queries. If a host has relevant information to the query, it sends a response packet.
You can see an example of an mDNS query/response in this CloudShark capture:
Similarly, here’s a query over IPv6 an example of a reverse query.
When testing a gateway or Wi-Fi router, CDRouter causes one of its simulated LAN hosts to send an mDNS query to the gateway, marking the test as a pass if it receives the proper response for both standard and reverse queries over IPv4 and IPv6.
Test DNS-SD record support
mDNS makes particular use of the DNS Service Discovery standard to allow hosts to include information about the kinds of services they offer (e.g. a printer offering a print service or a TR-369/USP agent announcing which message transports it supports).
If your device has any web services that it can offer over DNS-SD, test to ensure that it includes them in mDNS queries that ask for DNS-SD records. For home gateways, this usually means the configuration GUI, so that’s what we test for in CDRouter (consequently, you should skip this testing if your device doesn’t support a web GUI). You can see an example traffic flow of DNS-SD over mDNS here.
Test proper routing of mDNS traffic
Unlike other multicast traffic that might be forwarded from LAN to WAN, mDNS traffic is not intended to leave the LAN (and presents a security risk if so). For this reason, test that your devices don’t forward mDNS traffic to the WAN! CDRouter has a test in its mdns test modules to cover this specifically.
Test that mDNS works on all interfaces
You’ll want to make sure that you run your mDNS testing on many different LAN types. Test that it works on your product’s wired and wireless interfaces. In the case of Wi-Fi, it’s also essential to make sure that mDNS and multicast traffic, in general, will function properly over different/legacy Wi-Fi protocols, security modes, and channels.
Test multicast over IPv4 and IPv6
mDNS relies on multicast IP to operate. While your device may pass mDNS testing regularly, it’s also good to ensure that the general multicast functionality of your device is working correctly over both IPv4 and IPv6. While the CDRouter mcast test modules do some heavy lifting here to test Internet Group Management Protocol (IGMP) and MLD (for IPv6) features, running these modules against any device that plans on making use of multicast IP is a good idea.
Mix up your testing with other protocols
Like all applications and protocols, the reality of their performance on your device under test isn’t truly experienced until they are tested repeatedly and in the presence of other protocol and application activity. One of the advantages of repeatable automated testing that can be looped and run for long periods is that you can discover edge cases in a short amount of time that may take months or even years to appear in the field!
Pushing your device to reveal mDNS edge cases can be done by mixing this testing with other test cases, particularly those that stress the device. Examples of this include frequent DHCP release/renew sequences, scaling of the number of hosts connected to the device, running performance tests between your mDNS tests, and frequent Wi-Fi association/deassociations.
Use CDRouter’s ability to shuffle test cases, loop tests, and build custom test packages to push your device and reveal these mDNS edge cases sooner rather than later. And as always, these testing tips work best when considered as part of your overall testing strategy.