Date: Thu, 24 Aug 2006 10:46:50 -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: <93381966E13B960D4ACFF05C@garrett.local> In-Reply-To: <44EDCEC2.7060109@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> <7C6CDF1CB0BC58A6ADE1FCA8@garrett.local> <44EDCEC2.7060109@shapeshifter.se>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
In general, I agree with, and have been known to strongly champion, that
sentiment. But I also believe that programs should Do The Right Thing even when
the config file is missing. And in this case The Right Thing is to advertise
the hostname; since that will be the desired result in 99+% of the cases.
> > 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.
And that's one of the things that we'll have to fix if we want LLA and mDNS to
work correctly. The default should probably be to assume that they are
separate; but to recognize if they are in fact on the same link. That should be
easy enough to do since the LLA packets sent out on one interface will be seen
by the other one when they are on the same link.
> > 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.
The NSS module shouldn't have to know which domains mDNS is handling. It should
just attempt to resolve the FQDN given, using mDNS. If it fails, resolution
will fall back to the next module listed in nsswitch.conf. (I envision the
default as being: files mdns dns)
The problem with your proposal is that if the config file is missing, there is
no host advertisement at all. Also, that doesn't address the service
advertisement records. As I recall, the actual DNS records for service
discovery look something like _service._protocol.fqdn. So in the multi-domain
situation, you want each service to be -automatically- advertised as existing
in -all- of the host's 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?)
>
> 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.
I think our main point of disagreement here is on whether suitable default
behavior requires the presence of a (default) config file. With a minor
disagreement over how much of the configuration should be choosable via
/etc/rc.conf -vs- mdns.conf.
> 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.
> }
Adding IPv6 support wouldn't be quite as simple as just adding two more lines.
The default behavior needs to be able to handle all three cases: IPv4 only,
IPv6 only, and both. You don't want to advertise an A record if $(ifaddr) isn't
set. (And you do NOT want to issue an error/warning message. At least not
unless higher-than-default verbosity was explicitly requested.)
> > 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.
That's why the default should be to NOT advertise everything that is in
/etc/hosts. But it would be very convenient to not have to add/remove the same
mapping to two different config files.
Please note that I'm not saying that you shouldn't be able to add mappings
directly to the mdns.conf; only that if you are putting things into /etc/hosts
anyway, it might be useful to have the ability to just tell mdns to advertise
everything in /etc/hosts.
> 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.
Hmmm. You may be right about who is reading resolv.conf. But I'm not really
happy about the thought of adding yet another config file; especially since
some of the info (domain/search) is almost certain to need to be duplicated
between them.
Since we need some way to tell the mdns daemon which domain(s) to use if we're
using anything other than $(domainname); perhaps the mdns.conf can be shared
between the daemon and the nss module. Split the info into sections to make it
easier for each to know which parts they aren't expected to understand and put
all of the stuff they both want into a shared section.
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93381966E13B960D4ACFF05C>