On Thu, 16.11.06 17:45, Loïc Minier ([EMAIL PROTECTED]) wrote: > Hi, > > This is a followup for Debian bug <http://bugs.debian.org/393711
Hi! I am just coming back from the Ubuntu developers summit in Mountain View. We discussed the .local issues there and the Ubuntu guys decided to follow my suggestions and make nss-mdns authoritative for the mDNS/IPv4ll domains. To work-around the issues with .local in unicast DNS I recommended them to run a small script whenever DNS config changes. That script would use "host" to check whether .local is available in unicast DNS, and if so it would shutdown avahi and warn the user using syslog and the notification daemon (just by calling dbus-send if installed). In addition it would shut down the avahi daemon, since it is inherently incompatible with such setups. (shutting down the avahi daemon also deactivates nss-mdns, since Ubuntu compiles nss-mdns with --disable-legacy, which is something Debian should do as well.) The right place to call this script is in the hooks of Debian's "resolvconf" package. Since Ubuntu doesn't ship that package, they are going to put this script in dhclient's hook script. I truely believe that Debian should follow Ubuntu's lead here (of course using resolvconf hooks instead of the dhclient hooks directly). For more information about this, see https://wiki.ubuntu.com/ZeroConfNetworking under section "Implementation". And maybe: https://features.launchpad.net/distros/ubuntu/+spec/zero-configuration-networking > 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; I guess this is more or less similar to the "host" trick I was suggesting at uds-mtv. > 2) have an override over the result of this suite to permit explicitely > disabling or enabling mDNS; This seems to be available in the new avahi-daemon with a /etc/default fragment. I think it is a good idea to enable/disable nss-mdns and avahi-daemon always at the same time. If nss-mdns is compiled with --disable-legacy then /etc/default/avahi-daemon will also deactivate nss-mdns implicitly. as a side note: --disable-legacy disables the mini mDNS stack in nss-mdns and makes it rely exclusively on avahi-daemon for resolving. Because network access is then filtered through the chrooted/priv-dropped avahi-daemon process I nowadays recommend for all distributors for security reasons. The next upstream version of nss-mdns will probably change the default configure argument to --disable-legacy. Please note however, that nss-mdns will not work without avahi-daemon if compiled like this. Hence nss-mdns should replace "Recommends: avahi-daemon" with "Depends: avahi-daemon" if compiled this way. It might be advisable to build two versions of the libnss-mdns package, one with --disable-legacy (called libnss-mdns), the other one without "--disable-legacy" (called libnss-mdns-legacy). Please note that "legacy" in this context refers to the mDNS mechanism called "legacy lookups", not to the fact that one package would be "obsoleted" in a way by the other. > 3) enforce the configuration by either sweeping all mdns entries from > nsswitch.conf or by adding the relevant ones. I believe that we should not fiddle with nsswitch.conf aside from package installations/deinstallations. Remember that mdns is designed for mobile workstations like laptops which might change from networks where .local is defined in unicast DNS to others where it is not very often and during runtime. > 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 The trick I recommended at uds-mtv uses the SOA record of unicast DNS zones. See the wiki page for an example for this. > - "route" output, arp cache, conntracking table, "iptables -L" output: > check whether subnet 169.254.0.0/16 is in use. I don't see any point in doing this. In contrast to .local the network 169.254/16 is defined by the IETF for exclusive use in link-local adressing and has been so for quite a while (even since before the IPv4ll RFC was written). It's very unlikely that anyone uses 169.254/16 for anything but IPv4ll adressing. > 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). Same as IPv4ll here: this range has been defined by the IETF for exclusive link-local use. If anyone uses this for any other purpose he must be very misled or likes to shoot himself in the foot. With a very big gun. Using fe80: or 169.254.0.0 for anything but ll addressing is as stupid as using ::1 or 127.0.0.1 on eth0. > 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. As mentioned above, /etc/default/avahi-daemon can be used for this if nss-mdns is compiled with --disable-legacy. > 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. /etc/default/avahi-daemon also solves this. > > 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. The resolvconf hook solves this issue. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
