Hi,
This is a followup for Debian bug <http://bugs.debian.org/393711>.
On Tue, Oct 17, 2006, Lennart Poettering wrote:
> Sure, the line upstream recommends has also one disadvantage, which is
> that it is inherently incompatible with unicast DNS domains called
> .local. But that's the way mDNS has been designed, and is a simple fact
> that has to be dealt with administratively and not through applying
> ugly kludges to upstream's clean code.
My understanding of the problem so far is that it would be best if we
could have mdns be authoritative, but some sites are incompatible with
such a change. The authority would cover:
- direct lookups in .local domain,
- reverse lookups on IPv4 169.254.0.0/16 block,
- reverse lookups on IPv6 fe80::/16 block.
I propose the following on first installation, or on upgrade from prior
versions:
1) run a suite of tests to see whether the .local domain or the above
IPv4 blocks are in active;
2) have an override over the result of this suite to permit explicitely
disabling or enabling mDNS;
3) enforce the configuration by either sweeping all mdns entries from
nsswitch.conf or by adding the relevant ones.
Part 1) would typically be implemented in maintainer scripts or a
separate shell script and could use:
- /etc/hosts, "hostname --fqdn", reverse lookups of some particular
hosts (such as default gateway), or "route" or "iptables -L" output,
"dig -t NS local" on the resolv.conf nameservers: check whether the
domain .local is in use on this network
- "route" output, arp cache, conntracking table, "iptables -L" output:
check whether subnet 169.254.0.0/16 is in use.
I'm less sure about checking for fe80::/16; first I think IPv6 is less
common, so the intersection with sites using .local becomes smaller;
second, I fear that the route output always show fe80:: as it is used
for link-local addresses (anyone please correct me).
Perhaps it makes sense to run such a test suite on IPv4 and IPv6
separately, in order to turn on mDNS for one or the other or both (or
to leave it off).
Part 2) could typically be a /etc/default/libmdns file with
MDNS_BACKWARD_COMPATIBILITY=0 or 1. In the abscence of this file,
cached debconf responses would be used, and in the abscence of these,
the default value would be computed with the test suite, and if debconf
is at low priority, the user would get a debconf screen to override the
guess.
Part 3) could typically be offered by an "enable-mdns" script or
similar, as I believe is nowadays found under Ubuntu to enable mDNS.
This script would simply enforce whatever /etc/default/libmdns has, or
follow command line options. This script could also serve as a
lower-level "force turning off mDNS" or "force turning on mDNS"
administrative tool.
This script could also be called for part 1), this would permit
re-running the auto-detection.
Obvious problem of the proposal: roaming users with laptops. These
people should decide to either use .local for mDNS or for one of their
site.
Please comment on the above proposal, especially on whether it
completely solves the backward compatibility problem. Technical
suggestions for the implementation are of course welcome as well.
I'm not committing to the implementation of the above. :-P
Bye,
--
Loïc Minier <[EMAIL PROTECTED]>
10 SIN
20 GO TO ROBOT HELL -- Temple of Robotology
