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.
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:
You can see an example of an mDNS query/response in this CloudShark capture:
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.
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.
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.
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.
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.
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.