README.txt

   1 What is mDNSResponder?
   2 ----------------------
   3
   4 The mDNSResponder project is a component of Rendezvous,
   5 Apple's ease-of-use IP networking initiative:
   6 <http://developer.apple.com/macosx/rendezvous/index.html>
   7
   8 Apple's Rendezvous 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 Rendezvous than
  61 it would benefit from keeping Rendezvous 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 a "Platform Support" layer for OS X 10.2
  96 ("Jaguar"), and a "Platform Support" layer for other Posix platforms
  97 (OS X 10.1, Linux, etc.) Other support layers for platforms like Windows,
  98 VxWorks, etc. are also planned.
  99
 100 Note: Developers writing applications for OS X 10.2 ("Jaguar") do not
 101 need to incorporate this code into their applications, since OS X 10.2
 102 provides a system service to handle this for them. If every application
 103 developer were to link-in the mDNSResponder code into their application,
 104 then we would end up with a situation like the picture below:
 105
 106   +------------------+    +------------------+    +------------------+
 107   |   Application 1  |    |   Application 2  |    |   Application 3  |
 108   +------------------+    +------------------+    +------------------+
 109   |    mDNS Core     |    |    mDNS Core     |    |    mDNS Core     |
 110   +------------------+    +------------------+    +------------------+
 111   | Platform Support |    | Platform Support |    | Platform Support |
 112   +------------------+    +------------------+    +------------------+
 113
 114 This would not be very efficient. Each separate application would be
 115 sending their own separate multicast UDP packets and maintaining their
 116 own list of answers. Because of this, OS X 10.2 provides a common system
 117 service which client software should access through the
 118 "DNSServiceDiscovery.h" APIs.
 119
 120 The situation on OS X 10.2 looks more like the picture below:
 121
 122                                    -------------------
 123                                   /                   \
 124   +---------+    +------------------+    +---------+   \  +---------+
 125   |  App 1  |<-->|    daemon.c      |<-->|  App 2  |    ->|  App 3  |
 126   +---------+    +------------------+    +---------+      +---------+
 127                  |    mDNS Core     |
 128                  +------------------+
 129                  | Platform Support |
 130                  +------------------+
 131
 132 Applications on OS X 10.2 make calls to the single mDNSResponder daemon
 133 which implements the mDNS and DNS-SD protocols.
 134
 135 Vendors of products such as printers, which are closed environments not
 136 expecting to be running third-party application software, can reasonably
 137 implement a single monolithic mDNSResponder to advertise all the
 138 services of that device. Vendors of open systems which run third-party
 139 application software should implement a system service such as the one
 140 provided by the OS X mDNSResponder daemon, and application software on
 141 that platform should, where possible, make use of that system service
 142 instead of embedding their own mDNSResponder.
 143
 144 See ReadMe.txt in the mDNSPosix directory for specific details of
 145 building an mDNSResponder on a Posix Operating System.