Zeroconfig and Multicast DNS

[Pat Lashley]

> My responder does one thing (ok it's many things but anyway), it
> responds to queries and it makes queries. A mDNS record is always
> a mDNS record (shared or unique), at this point SD records are
> treated as any other record.
>
> Long-term records can be configured with responderd.conf, it
> supports dynamic variables such as $hostname, $ifaddr, $ifname etc.

As has been pointed out, avahi also allows services to be defined in a config 
file.

That's good; but it would be better if there were also a simple utility program 
that could add or remove records based on command-line parameters. Then it 
could be invoked by the rc script to better reflect whether or not the service 
is actually running. (And that means only one thing to change when 
enabling/disabling a service.)

Of course, having the daemon itself add the service record is even better; but 
that requires modifying the code for each daemon; and getting those 
modifications accepted back into the main distribution for those daemons. A 
simple utility script makes it easier to integrate non-mDNS-aware daemons into 
a zeroconf-based environment.

> Once the daemon is running, you are able to communicate with it
> through a UNIX pipe socket.
> Through this socket you're able to make queries, add/remove records,
> dump/flush the cache etc.
> Of course this allows you to create records through rc scripts on
> start up and removal of records on shutdown.

So basically, the command would be "echo '...' >> /path/to/pipe" ? That's 
certainly convenient; but I doubt that it is compatible with the other mDNS 
implementations. A common utility name and command-line API for that would make 
it much more likely that it would be adopted by the bundled rc scripts, even if 
the mDNS code is not bundled. (There's no reason that utility couldn't be a 
script

> Creating a library that mimic the API of mDNSresponder or gmdns
> around this pipe shouldn't be a problem, but I haven't studied any
> of their APIs so I can't say for sure.
>
> IMHO, SD really needs a set of standardized library calls, an application that
> wants to publish a SD record shouldn't need to
> worry about which type of responder program that is running on the host.

I believe that that's the point of the libdns_sd library in the mDNSResponder 
port, libgmdns in the gmdns port, and one of the several libraries in the avahi 
port.  They provide the service announcement/discovery API to be used by 
applications.  I haven't looked at either API; so I have no idea how compatible 
they are.  It would certainly be helpful to have a common API so that the 
choice of which to use could be made at application-load time.



As I investigate further, it appears that avahi is the most mature, 
feature-rich, and widely supported and adopted mDNS implementation.  The only 
potential drawback would be the GPL.

I've also discovered that Apple are moving the iCal server, Bonjour, and 
launchd to the Apache 2.0 license; which should be acceptable to those who 
don't like the GPL.  And apparently the Bonjour client libraries are already 
BSD licensed.



Overall, I think your work on the IPv4 Link Local Addressing is much more 
important and useful (and more likely to be adopted) than another mDNS 
implementation.  The LLA is the one piece that is currently missing for FreeBSD.




-Pat