If you are working in the IoT ecosystem, chances are that you may have come across the terms ‘mDNS’ (short for multicast Domain Name System) and DNS-SD (SD stands for Service Discovery). Chances are that you may have even implemented mDNS and/or DNS-SD without a complete understanding of the concept (I’ve been there, done that). Interested in understanding the topics in-depth? Read on!
First of all, what is DNS again?
Very crudely, you can think of DNS as a phonebook for the internet. Take this website for example. iotespresso.com is essentially a bunch of web pages sitting on a machine somewhere in North America. This machine runs a web server that helps it serve these web pages to clients (like you) over the internet. This machine is identified by an Internet Protocol (IP) address on the internet. It is through this IP address that other machines on the internet are able to find this machine.
Now, as a user, you will not want to type in the IP address of this machine every time you want to access this website. You’ll want a more nice-looking, easy-to-remember name. That’s why I purchased the domain iotespresso.com and linked it to my website. Now, you can type this easy-to-remember name in your browser and access this site. But wait! How does the browser know which IP address to query when you type iotespresso.com? Come in DNS!
The browser first queries a DNS server with the domain of the website. This server then tells the browser what IP the domain corresponds to. The browser can then query the IP and get you the required web pages.
Which DNS server does the browser query? Well, that is generally dictated by your network. On your PC, you can open the command prompt, and type in ipconfig/all. You’ll find the DNS servers listed.
You may notice that the DNS Servers change if you change your network (switch to a different Wi-Fi). Where do the DNS servers come from? You can find out here.
Great! So what is mDNS now?
If you understood DNS, you would have also understood that it is a one-to-one (unicast) protocol. Your machine queries a fixed DNS server and gets the response. And of course, the DNS query happens over the internet.
multicast DNS is the DNS equivalent for a local network. Note the two highlighted words in the previous sentence. They pretty much sum up the difference between DNS and mDNS.
Consider a room that has several devices (mobile phones, laptops, televisions, printers, etc.) connected over a common Wi-Fi network. The Wi-Fi network may or may not have access to the internet, that doesn’t matter. What matters is that they share a common network. Now, consider a situation where I need to send a command from my mobile phone to my printer to start printing. The mobile phone will need to connect to the printer. And it will need the IP of the printer for that (the IP provided by the Wi-Fi router). How does it get it? Simply by asking everyone on the local network if they are the intended printer. Yes, really!
In mDNS, there is no central DNS server, i.e., no central phone book. If you wish to query an IP whose hostname you are aware of, then you send a multicast message to all the devices in the network asking if any of them identify with the hostname. One of the devices will match the hostname that you are querying. It will then respond with its IP address (again via multicast, to all devices on the network). All the devices on the network can then update their local phonebook (mDNS cache), mapping the hostname with the local IP.
Cool, now what is DNS-SD?
mDNS can also be used in conjunction with DNS-based Service Discovery (DNS-SD). Most of the devices also provide some services to other devices on the same network. For example, a printer may provide messaging services over TCP on port 5566. Instead of searching by the hostname, if you search by the service name (by sending a DNS-SD request over mDNS), you can get the hostnames providing these services, and then mDNS can resolve these hostnames to the corresponding IP addresses.
Thus, using mDNS in conjunction with DNS-SD, if you search for, say, a service named ‘._print._udp’, you will get a list of all devices on the local network that provide this service, their hostnames, their IP addresses, and the port on which they provide this service (you can also search for a specific port). Now you can connect to the device of your interest, using the protocol specified in the service, over the specified port and perform the necessary action.
The concept is fine, but what are the specifics?
You typically need not worry about the specifications when you use a library to implement mDNS and/or DNS-SD. However, knowing won’t hurt, right?
The multicast query is always executed on either IPv4 address 18.104.22.168 or IPv6 address ff02::fb. It is a UDP message, on port 5353. BTW, unicast DNS is also a UDP message, on port 53.
The resolution of hostnames to IP addresses is only allowed for hosts ending with .local suffix (as opposed to .com, .in, etc. extensions for normal websites). Hostnames ending with extensions other than .local are not processed by mDNS.
Apple Bonjour and Avahi software (on Linux distributions) implement both mDNS and DNS-SD. Windows 10 has also started providing native implementation for mDNS and DNS-SD. See this.
Does it help in IoT?
Of course! As you would have guessed, mDNS (along with DNS-SD) finds applications in discovering smart devices on the local network, based on either the hostname or the service. Once discovered, you can configure and interact with the devices over the local network itself. A lot of smart home devices available in the market today support mDNS based discovery.
In order to implement a working example for yourself, you can see this tutorial on How to discover ESP32 service over mDNS.
Several articles helped me prepare this one. Listing them below:
Found this post helpful? Then check out further posts on iotespresso.com.