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 */,' {} \; |
---|