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