Zeroconfig and Multicast DNS

[Pat Lashley]

> 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