Zeroconfig and Multicast DNS

[Pat Lashley]

> > Actually, that is IPv4 Link Local Addressing. Zeroconfig includes that,
> > Multicast DNS, Service Discovery and anything else that removes the need
> > for manual configuration.
>
> Yeah, I actually know that. It's just that I've developed a bad habit of
> calling it zeroconfig in the absence of a short name, calling it
> "ipv4 link local addressing" every time tends to get a bit tedious.
> But I should not have done that in my previous mail, my apologies.

After a quick look at your website, I figured you were probably aware of the 
correct usage; but thought that it might be a good idea to clarify the point 
for others on the list who might be new to the idea.


> > I'm very glad to hear that somebody is working on IPv4 Link Local for
> > FreeBSD.
> >
> >> Multicast DNS is DNS without a server, you can think of it as mixing
> >> ...
> >
> > Doesn't the net/mDNSResponder port handle both mDNS and (m)DNS-based
> > service discovery? Is it missing some functionality that can't be easily
> > handled by a wrapper?  (E.g. An nss_mdns that uses their libdns_sd.so)
> >
>
> I didn't know there was a port of Apples daemon and I'm sure it
> works just fine. The only thing that might be an issue is licensing
> terms, at least in embedded solutions. My code is under a BSD license.

Actually, the Apple license looks pretty reasonable; even for embedded 
applications.

> I'll continue to hack on my responder anyway, as it's not that
> far from completion.

Since sending that email, I also discovered that there's a net/gdns port for 
the GNU version. But it appears to be under the GPL; which would be more of an 
issue.

I just thought that it might be easier to work with one of these established 
projects.

> The service discovery part is just a set of records in the responder
> which it responds to, a service discovery client/agent is needed to
> find announced records.

The Apple way seems to assume that the individual applications will be linked 
with the service discovery library. I'm not sure that they even provide a 
method for the end-user to browse all available services. There is a 
postcard-ware third-party app called Browsejour from bleepsoft; but I'm sure 
that it's GUI is OS X specific. A browsing utility would certainly be useful; 
but if I were starting such a project, I'd write it to use one of the existing 
libraries from the ports. (Ideally choosing which at build time.) Of course, 
you aren't just starting your project, you're fairly well along; so I can 
understand your reluctance to switch.

Is your library API fairly close to the one in mDNSResponder or gmdns? If so, 
it should be fairly easy to make your apps work with whichever library is 
installed. (I'm just thinking ahead to the point where projects like Apache, 
Firefox, and various GNOME apps have added service announcement/discovery and 
sysadmins are asking themselves why they need three different mDNS libraries 
installed at once...)

Also, you mention the discovery client/agent; but not the advertisement. I'd 
really like to see an easy way to advertise services without having to modify 
the daemons to announce themselves. I'm particularly thinking of long-running 
daemons for services like http, ssh, ftp, etc.; where the service is generally 
made available as part of the boot sequence. It would really be great if the 
service advertisement could be done as a one-line addition to their rc scripts. 
(Something like: '[ -x /path/to/announcer ] && announce service' would be safe 
even if the mDNS stuff isn't installed.  Actually, I suppose you'd also want a 
line to revoke the annoouncement in the 'stop' section. )



-Pat