Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Aug 2006 08:28:10 -0400
From:      Pat Lashley <patl@volant.org>
To:        Fredrik Lindberg <fli+freebsd-net@shapeshifter.se>
Cc:        freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org>
Subject:   Re: Zeroconfig and Multicast DNS
Message-ID:  <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local>
In-Reply-To: <44ED8266.1060303@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> <5D7785ADC030FEBFB9A5E69D@garrett.local> <44ED8266.1060303@shapeshifter.se>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.

No argument there.

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

The HINFO record should be a policy decision; but I'm much less certain about 
the utility of not advertising a hostname.

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

Things get a bit more complex for multi-homed hosts; especially if they are 
connected to more than one local link using IPv4 Link Local Addressing...

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

As I mentioned in an earlier posting, I would really like to see it support 
multiple TLDs for a single host. In particular, if I'm using example.com, then 
mumble.local and mumble.example.com should both resolve via mDNS to the IP 
address of host mumble. Similarly, services advertised by host mumble should 
automatically be listed in both domains.

If we're going to require an entry in a config file to get address 
advertisement; then we need to ensure that the default config file Does The 
Right Thing for the 99.99% case. (Otherwise, it isn't really zeroconf, is it?)


I think that it would be best if the most common cases worked correctly without 
a config file at all. Command-line flags set via /etc/rc.conf can indicate 
interfaces that are (not) to be used, whether or not to automatically produce 
an HINFO record, and whether to advertise all (except 127/8) or none of the 
/etc/hosts records. Doing this via rc.conf makes it much easier to set up 
common options at install time via sysinstall.

The config file, if provided would specify additional hosts that don't 
advertise themselves; and additional services provided by hosts that don't 
advertise. It would also be used to specify a non-default HINFO record format. 
(I'm thinking a string with various % substitutions available.) Note that 
whether or not to produce an HINFO record at all would still be handled by the 
command line.

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

No, programs announcing a service using SD would preferably make a call to the 
mdns-sd library. The use of the mdnstool in the rc.d script should probably be 
viewed as the preferred method during the transition period between bundling 
the basic mDNS support and converting the service providers to being directly 
mDNS-aware.

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

Is that really necessary? I haven't looked at how the resolver handles the 
domain search list and how that relates to NSS calls; but couldn't it be 
handled by implicitly adding 'local' to the list?



-Pat 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7C6CDF1CB0BC58A6ADE1FCA8>