Zeroconfig and Multicast DNS

[Fredrik Lindberg]

Pat Lashley wrote:
>> 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.
> 

I should probably explain better what I mean with this mdns.conf file,
as I think there might be a misunderstanding about it.

Let us for a second pretend that SD doesn't exist but mDNS does, mDNS
without SD is still a very valuable protocol.
The specs. says that each host should claim a unique host and also
advertise a HINFO record, but this in my opinion a policy decision
and should be left to the end user.
A user might want to advertise 0, 1, 2 or many different unique records,
and the main purpose of the mdns.conf file would be to provide a easy
way to do so (without writing scripts that calls a cmd line utility).
For example, a line in the mdns.conf might look like this

   $(hostname).local. A  $(ifaddr)

Might look cryptic but it just means announce a A record using my
current hostname, append .local. and point it to whatever ip number
that happens to be configured on my interface. These variables would
be updated when things happen in the system (new ip address etc)
Also, there is no technical limitation in the mDNS protocol that
prevents it from working with other TLDs, so which TLD to use should
also be up to the user (again a policy decision).

Now we can get back to the reality where SD does exists.
In addition to this mdns.conf we have the client API, using this
client API a command line tool should be built that can insert
and remove records (even those records configured using mdns.conf).
Lets call this tool mdns for now (the name it doesn't matter, and
isn't really the point).

Programs announcing a service using SD would preferably call the
mdns tool in their rc.d scripts to add/remove SD records.

So I'm not voting for either side, I want 'em both and I definitely
want a command line tool that rc.d-scripts can call to register records.


> 
>> > 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.)

If KDE and Gnome are using the Avahi API, then we really need to support
it. But as you said we can probably implement both APIs as shim calls
around our own API.


>> > 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?

>> 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.
> 

I've been thinking about this too. The NSS module would require a file
similar to resolv.conf. It would contain a "white list" of allowed
domains to resolv (local., 168.192.in-addr.arpa., 10.in-addr.arpa etc).
But it could also contain a "search" directive so that if it receives
a query for a name without a white listed TLD it appends for
example ".local." to the name.
It might be dangerous though as it could try to query for
www.google.com.local., a solution to this would be do "blacklist"
existing TLDs when a search is done or only to do a search if there are
no dots in the name, I think the latter solution is the best
Anyway, it would allow users to leave out the .local part when 
communicating which I think would be a nice feature.

Fredrik Lindberg