Zeroconfig and Multicast DNS

[Fredrik Lindberg]

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

Ah, ok, ok. Let's say our responder has the ability to parse a mdns.conf
and if that file is missing then I very much agree

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

Um...I'm not sure if this is even possible. Let's forget mDNS and
go back to basic IP.
Say a multi-homed host has two interfaces both configured with an
address in the rage 169.254/16, say 169.254.1.1 and 169.254.2.1 and
it wants to initiate a connection to 169.254.3.1, how on earth should
it be able to tell on which side 3.1 is located? There might even be
one 3.1 on both side that could be completely different hosts.


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

Ok, some kind of alias that will propagate for all records. I don't
have a good solution to it yet, I need to think about this but I do
get your point (and I can see the benefit with it).

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

This suggestion is VERY VERY dangerous. Any responder on the network
could very well decide to respond to for example www.google.com (or to
the address of your internet banking site). What you see in your browser
would be www.google.com and the page might look like google but you
won't be at the site you think. Having the responder resolve names
with real TLDs means that it will resolve names that it does not have
the authority over.

The nsswitch.conf should IHMO be :files dns mdns, and the mdns nss
module should ship with a default to only allow queries to
   .local
   .168.254.in-addr.arpa
   .168.192.in-addr.arpa
   .16.172.in-addr.arpa-31.172.in-addr.arpa
   .10.in-addr.arpa

And whatever set of IPs that are assign as link/site-local for IPv6,
I don't remember them at the moment.
However it should be possible for a user to add whatever TLD he/she
wants or disable the restriction all together. But the default should
be restricted to prevent name spoofs.

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

Ok, so if no mdns.conf is available then the responder will attempt
to register hostname.local (and a ptr record), but if a mdns.conf IS
available it takes precedence over the default behavior.
I think I can go along with that.

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

Of course, of course. If no data is available for a record, that record
would not be used. (This is more or less implementation details).

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

Hmm..I'm not sure, but as long as it's not default behavior it's just
another way of adding records. And users might find it handy so I guess
it would be a possible option.

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

Yes, that's certainly a possibility and will reduce the number of
configuration files.

Fredrik Lindberg