Date: Thu, 24 Aug 2006 18:07:30 +0200 From: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> To: Pat Lashley <patl@volant.org> Cc: freebsd-net@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <44EDCEC2.7060109@shapeshifter.se> In-Reply-To: <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> 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> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Pat Lashley wrote:
>>
>> 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.
Well, then we can agree upon disagreeing :)
I guess it's just my nature, I really don't want to restrict end users
ability to do stuff when there is no TECHNICAL limitation of doing so.
It's the classical policy versus mechanism scenario, imho policy should
be left to the user, of course provided with sane default values that
can be used out of the box.
>
>> 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...
Well, I already have a proof-of-concept of this running a multi-homed
responder and hosts on both ends resolve the addresses correct.
A multi-homed host with two interfaces configured in 169.254/16 will
have other major problems beyond mDNS as the host would threat
both interfaces as being on the same net even if they are
physically separated.
>
> 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.
Well, $(hostname).example.com. A $(ifaddr) :)
You would have to configure the NSS module to allow .com queries too.
>
> 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?)
Of course, default configuration should always be such that it requires
none or minimal work by the end user to get it running with values
that suite most people. However I feel power-users shouldn't be
restricted to do what ever they want, even how crazy other people
might think it is.
The default of my proof-of-concept stuff had this as default, which
means advertise a A and a PTR record for my hostname on all interfaces
using the address of the interface. (should be expanded with AAAA and
$(ifaddr6) in a real application).
interface * {
$(hostname).local. A $(ifaddr)
$(ifaddr) PTR $(hostname).local.
}
>
>
> 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.
I really don't understand how it should read /etc/hosts, users might
have aliases in there that doesn't belong to them which would make
the responder announce records that doesn't belong to them.
>
> 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.
Yeah, on a second though I agree with that.
>
>> > 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?
>
I was under the impression that resolv.conf was explicitly used by the
dns nss module, but I could be wrong. The mDNS will requires its own
nss module that should be independent from the other DNS.
Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44EDCEC2.7060109>