1What is mDNSResponder? 2---------------------- 3 4The mDNSResponder project is a component of Bonjour, 5Apple's ease-of-use IP networking initiative: 6<http://developer.apple.com/bonjour/> 7 8Apple's Bonjour software derives from the ongoing standardization 9work of the IETF Zero Configuration Networking Working Group: 10<http://zeroconf.org/> 11 12The Zeroconf Working Group has identified three requirements for Zero 13Configuration Networking: 141. An IP address (even when there is no DHCP server to assign one) 152. Name-to-address translation (even when there is no DNS server) 163. Discovery of Services on the network (again, without infrastucture) 17 18Requirement 1 is met by self-assigned link-local addresses, as 19described in "Dynamic Configuration of IPv4 Link-Local Addresses" 20<http://files.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal.txt> 21 22Requirement 2 is met by sending DNS-like queries via Multicast (mDNS). 23 24Requirement 3 is met by DNS Service Dicsovery (DNS-SD). 25 26Self-assigned link-local address capability has been available since 271998, when it first appeared in Windows '98 and in Mac OS 8.5. 28Implementations for other platforms also exist. 29 30The mDNSResponder project allows us to meet requirements 2 and 3. 31It provides the ability for the user to identify hosts using names 32instead of dotted-decimal IP addresses, even if the user doesn't have a 33conventional DNS server set up. It also provides the ability for the 34user to discover what services are being advertised on the network, 35without having to know about them in advance, or configure the machines. 36 37The name "mDNS" was chosen because this protocol is designed to be, 38as much as possible, similar to conventional DNS. The main difference is 39that queries are sent via multicast to all local hosts, instead of via 40unicast to a specific known server. Every host on the local link runs an 41mDNSResponder which is constantly listening for those multicast queries, 42and if the mDNSResponder receives a query for which it knows the answer, 43then it responds. The mDNS protocol uses the same packet format as 44unicast DNS, and the same name structure, and the same DNS record types. 45The main difference is that queries are sent to a different UDP port 46(5353 instead of 53) and they are sent via multicast to address 47224.0.0.251. Another important difference is that all "mDNS" names 48end in ".local." When a user types "yourcomputer.local." into their Web 49browser, the presence of ".local." on the end of the name tells the host 50OS that the name should be looked up using local multicast instead of by 51sending that name to the worldwide DNS service for resolution. This 52helps reduce potential user confusion about whether a particular name 53is globally unique (e.g. "www.apple.com.") or whether that name has only 54local significance (e.g. "yourcomputer.local."). 55 56 57About the mDNSResponder Code 58---------------------------- 59 60Because Apple benefits more from widespread adoption of Bonjour than 61it would benefit from keeping Bonjour proprietary, Apple is making 62this code open so that other developers can use it too. 63 64Because Apple recognises that networks are hetrogenous environments 65where devices run many different kinds of OS, this code has been made 66as portable as possible. 67 68A typical mDNS program contains three components: 69 70 +------------------+ 71 | Application | 72 +------------------+ 73 | mDNS Core | 74 +------------------+ 75 | Platform Support | 76 +------------------+ 77 78The "mDNS Core" layer is absolutely identical for all applications and 79all Operating Systems. 80 81The "Platform Support" layer provides the necessary supporting routines 82that are specific to each platform -- what routine do you call to send 83a UDP packet, what routine do you call to join multicast group, etc. 84 85The "Application" layer does whatever that particular application wants 86to do. It calls routines provided by the "mDNS Core" layer to perform 87the functions it needs -- 88 * advertise services, 89 * browse for named instances of a particular type of service 90 * resolve a named instance to a specific IP address and port number, 91 * etc. 92The "mDNS Core" layer in turn calls through to the "Platform Support" 93layer to send and receive the multicast UDP packets to do the actual work. 94 95Apple currently provides "Platform Support" layers for Mac OS 9, Mac OS X, 96Microsoft Windows, VxWorks, and for POSIX platforms like Linux, Solaris, 97FreeBSD, etc. 98 99Note: Developers writing applications for OS X do not need to incorporate 100this code into their applications, since OS X provides a system service to 101handle this for them. If every application developer were to link-in the 102mDNSResponder code into their application, then we would end up with a 103situation like the picture below: 104 105 +------------------+ +------------------+ +------------------+ 106 | Application 1 | | Application 2 | | Application 3 | 107 +------------------+ +------------------+ +------------------+ 108 | mDNS Core | | mDNS Core | | mDNS Core | 109 +------------------+ +------------------+ +------------------+ 110 | Platform Support | | Platform Support | | Platform Support | 111 +------------------+ +------------------+ +------------------+ 112 113This would not be very efficient. Each separate application would be sending 114their own separate multicast UDP packets and maintaining their own list of 115answers. Because of this, OS X provides a common system service which client 116software should access through the "/usr/include/dns_sd.h" APIs. 117 118The situation on OS X looks more like the picture below: 119 120 ------------------- 121 / \ 122 +---------+ +------------------+ +---------+ \ +---------+ 123 | App 1 |<-->| daemon.c |<-->| App 2 | ->| App 3 | 124 +---------+ +------------------+ +---------+ +---------+ 125 | mDNS Core | 126 +------------------+ 127 | Platform Support | 128 +------------------+ 129 130Applications on OS X make calls to the single mDNSResponder daemon 131which implements the mDNS and DNS-SD protocols. 132 133Vendors of products such as printers, which are closed environments not 134expecting to be running third-party application software, can reasonably 135implement a single monolithic mDNSResponder to advertise all the 136services of that device. Vendors of open systems which run third-party 137application software should implement a system service such as the one 138provided by the OS X mDNSResponder daemon, and application software on 139that platform should, where possible, make use of that system service 140instead of embedding their own mDNSResponder. 141 142See ReadMe.txt in the mDNSPosix directory for specific details of 143building an mDNSResponder on a POSIX Operating System. 144 145 146Compiling on Older C Compilers 147------------------------------ 148 149We go to some lengths to make the code portable, but //-style comments 150are one of the modern conveniences we can't live without. 151 152If your C compiler doesn't understand these comments, you can transform 153them into classical K&R /* style */ comments with a quick GREP 154search-and-replace pattern. 155 156In BBEdit on the Mac: 1571. Open the "Find" dialog window and make sure "Use Grep" is selected 1582. Search For : ([^:])//(.*) 1593. Replace With: \1/*\2 */ 1604. Drag your mDNSResponder source code folder to the Multi-File search pane 1615. Click "Replace All" 162 163For the more command-line oriented, cd into your mDNSResponder source code 164directory and execute the following command (all one line): 165 166find mDNSResponder \( -name \*.c\* -or -name \*.h \) -exec sed -i .orig -e 's,^//\(.*\),/*\1 */,' -e '/\/\*/\!s,\([^:]\)//\(.*\),\1/*\2 */,' {} \; 167