Zeroconfig and Multicast DNS

[Pat Lashley]

First, I'd like to correct something that slipped by earlier. Service Discovery 
via DNS does -NOT depend on mDNS; it may be implemented using traditional 
unicast DNS. (And to a pure client, there should be no detectable difference.)


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

No, it shouldn't depend on whether the file is present or not. The defaults 
should be reasonable; and the config file should be able to override the 
defaults. You should -never- have to put anything in the config file to obtain 
behavior that would be chosen automatically if the config file were absent.

It should be possible to explicitly specify behavior that matches the default; 
just for those of us who don't always trust the defaults not to change. But it 
shouldn't be necessary just because a config file exists. An empty, or 
comment-only config file should produce the same behavior as a missing one. A 
config file with one default behavior explicitly specified should also produce 
the same behavior as a missing config file, or one that explicitly specifies 
all of the options as matching the defaults.

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

Yep, that's distinctly possible. BUT, remember, the 169.254/16 network can't 
really be sub-netted. So that situation would only occur if the interfaces are 
on separate 'local' links.

My claim is that when the host does its initial 'I want to use this address' 
broadcast on interface 1, it should also -receive- that packet on interface 2 
IFF the two are on the same link. It shouldn't have any trouble distinguishing 
its own request from some other host's request for the same IP address. (For 
one thing, it should know all of its own MAC addresses.) So it shouldn't be too 
hard to automatically determine whether its interfaces are on the same link or 
not.

(It could do a simple same-physical-link check by trying to send an Ethernet 
packet from interface 1 to the MAC address for interface 2; but that may not 
handle all of the cases where there's an external bridge connecting two 
physical segments into one logical 'local link'. It would also require further 
adaptation for non-Ethernet interfaces. So recognizing its own RFC-3927 packets 
is probably the best way to go.)

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

I think you meant .254.168.in-addr.arpa here.

>    .168.192.in-addr.arpa
>    .16.172.in-addr.arpa-31.172.in-addr.arpa
>    .10.in-addr.arpa

I put mdns before dns for performance reasons. If you restrict the queries as 
defined above, there's no real advantage to doing the dns query first.

I am reluctantly coming to agree that for security reasons we need to restrict 
the domains for A record lookups via mDNS; and PTR records in the in-addr.arpa 
domain.

But service discovery will often have a non-.local domain; so I think we need 
to allow PTR/SVC/TXT lookups in any domain. (Or possibly anything outside 
in-addr.arpa. Given the existence of the .local domain, I don't see any utility 
in advertising a service in an in-addr.arpa domain. I'm sure somebody will post 
an example if I'm just being short-sighted here...)


> And whatever set of IPs that are assign as link/site-local for IPv6,
> I don't remember them at the moment.

Isn't link-local the fe80:: network? I don't remember the site-local network 
ID; and it isn't automatically set; so I can't find it via 'ifconfig -u'.

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

Yes, I'm afraid you're right.


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

No, if a mdns.conf file IS available, it will still register hostname.local 
(and the PTR record); UNLESS the mdns.conf explicitly asks it not to. Assuming, 
of course, that IPv4 is enabled on that interface. The mere presence of a 
config file should -NOT- alter default behavior.

And the same goes for the AAAA record if IPv6 is enabled on the interface.

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

Not entirely. It is also a syntactic/semantic issue in the config file design. 
There's a choice between whether there's an implicit "ignore this if the 
necessary protocol isn't available" or some sort of conditional block to 
explicitly say 'if condition X, then apply the following set of options'. The 
later is potentially more powerful.

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

That's my thought. I don't personally expect to use it; but I think it's useful 
enough to be readily available.




-Pat