Date: Wed, 23 Aug 2006 14:50:09 -0400 From: Pat Lashley <patl+freebsd@volant.org> To: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se>, Doug Barton <dougb@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: Zeroconfig and Multicast DNS Message-ID: <5D7785ADC030FEBFB9A5E69D@garrett.local> In-Reply-To: <44ECBB61.9020808@shapeshifter.se> References: <44E9F991.7020309@shapeshifter.se> <DD49A62B2AB4E38804FB10B6@garrett.local> <44EA1926.2000501@shapeshifter.se> <9C04919EE684029A410DE208@garrett.local> <44EAC40E.9000904@shapeshifter.se> <3E654CC0217F90E20FCD806E@garrett.local> <44EC90B7.6090908@shapeshifter.se> <44ECB0F2.9040300@FreeBSD.org> <44ECBB61.9020808@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 2. What are the linux flavors doing? > > It appears that the Avahi (http://avahi.org/) responder is the > current leader, it's API compatible (client wise) with mDNSResponder. It is my impression that the mDNSResponder API compatibility lib/shim is a build-time option and not actually used by the rest of the Avahi code. >> 4. What are the nice to haves? > > IMHO, mDNS. One of the things that I forgot to mention is that it would be nice if the mDNS handled both the .local domain and one or more specific domains easily. In particular, if I have a host named 'mumble' and tell mDNS that my domain is lan.example.com; then I would like both 'mumble.local' and 'mumble.lan.example.com' to resolve (and be advertised) via mDNS. Similarly for any services advertised on that host. And I'm assuming that once we have Zeroconf support, it will be in the configuration used by sysinstall on the installation ISO image... (It shouldn't have much, if anything, to advertise except a hostname and IP address; but could make good use of LLA and service discovery.) > > 7. How should the sysadmin interact with this, and what knobs should they be > > able to twiddle? (LLA address parameters, definitions of unique services, > > access limitations ala hosts.allow?) > > As for lla, it's really zeroconfig by nature and more or less dhcp > without a server. A suitable configuration is something such as LLA in > the ifconfig_if0="" line in rc.conf (similar to DHCP or WPA). At my previous job, I worked with the busybox zcif LLA implementation for an embedded client. I found it annoying that there was no way to have a single interface with both LLA and non-LLA addresses. I would argue strongly for an rc.conf setup that allows us to specify that LLA is to be performed on an interface, even if an address is obtained via some other mechanism. In particular, it would be nice to be able to specify both LLA and DHCP. (And to specify that DHCP failure is OK.) > As for mDNS/SD I think a generic responderd.conf/mdns.conf file should > be available where you can configure "static" dns records. I would really rather see the service advertisement done in each service's rc.d script. That has the advantage of not requiring the mdns.conf file to be updated if the _enable knob is changed in /etc/rc.conf. It also makes it easy to add a line to revoke the advertisement in the rc.d script's 'stop' action. That said, static service advertisement via the mdns.conf file is useful when advertising on behalf of of a system or embedded device that doesn't have native mDNS support. (E.g., An older network-attached printer.) The mdns.conf can also be used to advertise host records for hosts that don't support mDNS. But again, it would be nice to have a config flag that just says 'advertise everything in /etc/hosts' in addition to a way to list individual entries. > Programs will be able to register/announce records through the client > API (it talks to the responder via a unix pipe socket). Right. Applications that are mDNS-aware just use the library API to announce/revoke their availability and to browse for services they may want to use. And eventually, I think that we want to integrate mDNS-awareness in all of our bundled services and any apps for which service browsing makes sense. The rc.d script utility calls mentioned above are intended to handle the transition period while we have the basic mDNS functionality but haven't yet converted all of the services to use it. > Various utilities should be available so that an administrator is able > to add/remove records from the command line and via scripts. Right. Also to browse both host records and service advertisements. > > 8. How should applications interact with this system? That includes stuff in > > the FreeBSD base, and what APIs to publish for third party stuff. Are there > > well established APIs that we should/must support? > > It's best to go with Apples API from mDNSResponder. It's not clear to me yet whether it is better to do that or to go with the Avahi API; or to provide both. (I haven't actually looked at either; so I don't know just how they differ.) > > 9. At some point we have to bring the ports guys in on this too, with a goal > > in mind of determining what features we'd need to support in the base to > > eliminate the need for an mDNS implementation in ports. (The fact that we > > currently have 2, slightly incompatible implementations in ports now is > > already giving me a headache.) > > See previous answer. Supporting different APIs might be possible but > not as a start. Again, it isn't clear just how different the two main API sets are; or how hard it would be to support both. It's quite possible that one set of the API would just turn into a set of shim calls that invoke the other one. > > 10. How do users interact with this? Should there be a utility that allows > > users to browse the network to see what services are available? > > This is where the Service Discovery protocol comes in, it runs on top of > mDNS and are basically just dns records peers announce when they would > like to tell the world about services they are providing. > Having such utility would probably be nice. I see this as mainly important for sysadmins. There's a good chance that end users will have GNOME and/or KDE installed; and already have a GUI-based service browser. > As for mDNS and hostname in generic, users would interact with them just > as with any other dns records or name. Right. Except for the additional bit of knowledge about the .local domain. > It's nice that others have seen the zeroconfig light :) Hear! Hear! -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D7785ADC030FEBFB9A5E69D>