Bug#433945: avahi-daemon: .local in unicast detection not perfect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: avahi-daemon Version: 0.6.19-2 Severity: normal I've been thinking about this.. specifically why OSX has no problems with DNS domains ending in .local and avahi does (and also that .local in unicast detection can never work because that's not the root of the problem IMO). A company I work with has a domain ending in .local, historical, because when they started they were a purely OSX shop and that's what their limited knowledge said was good. It's since sprouted a few active directory servers, exchange email, etc. Changing just isn't going to happen. In this environment from this OSX box I can ping any box in the domain - OSX works perfectly. avahi breaks in various ways, causing all sorts of wierd effects. What OSX is doing is distinguishing betweeen foo.bar.local and foo.local - - the former is purely a DNS domain, and the latter is an mdns query. This is shown where bar.local has an A record but OSX cannot in fact resolve it.. it goes to mdns and aborts. foo.bar.local responds immediately. avahi doesn't appear to do this.. it sees the .local, gets somewhat confused and barfs (even if I rename a machine to foo.bar.local experimentally and run avahi on it it can't resolve it, so it's not working at all). As to why the .local detection can't work - because on domains that avahi has a problem with .local probably doesn't exist.. bar.local might, but on a local DNS server it would be unusual to define the root TLD like that. I don't *think* anyone is actually using the .local domain itself (never seen it, myself). Also the solution proposed in message #5 wouldn't work in the case I'm seeing - these are domains coming in over VPN not defined in resolv.conf.. there's probably no way of detecting it automatically. I propose that avahi be changed to match the OSX behaviour. It's not perfect, but it'd break a *lot* less systems. Tony -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.12 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLKW1YAAoJEJ1qCQ6ePCDUXuoH/RhpKRQw/LWhDJ/TXf+oj+Jj 9sIrUu3qPOp2NI2JczmS7Y3UMfe9bQsunLZlIyF0GxXWZ3qsuvfQ1L0ghyHfIbL5 HmPgJJ1m6IYcQSSYh5fdhXS5NLmWSAMhvvgQFy57FsLzDfU5XOGevBl7SmAh34yb kKhX60xyml5KaoSR2yXhc/HptMx2JxhxUzvhLnrWtKOs39st2fYZiHSUXPlesSWD ORCt/Q1KMp7isGPv/jGiIhbIOC49TUhJi+p2JSYhKol6143HQ6Pn5dMOxMKHAvrt r3YhJKt3d1juGCXANk40MZFV9cyaEwI1VTzBPO7qvLm9UxfBZeKFb/+z1S83o+I= =m72g -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#433945: avahi-daemon: .local in unicast detection not perfect
Package: avahi-daemon Version: 0.6.19-2 Severity: normal The .local-in-unicast-dns detection is not perfect. Apparently some IP routers do not properly respond to SOA queries if asked for non-existing domains. One example being the WLAN router of the ETAP hotel here at GUADEC in Birmingham. This router has a catchall DNS set up and sometimes responds with an A RR if asked for a SOA RR. This has the unfortunate effect that the query doesn't fail and the check script wrongly assumes that there is a unicast DNS domain called .local while there actually is not. The host command seems not to check whether the data in a DNS response packet actually matches the data in the DNS query packet. To work around this the check script should check if the output of host actually includes real SOA data. OTOH there are a couple of unicast DNS set ups around where RR definitions reside in a subhierarchy of .local, i.e. foo.bar.local instead of just foo.local. If bar.local itself does not exist in the DNS zone files this case is not detect as .local in unicast DNS cases, while it actually should. I would suggest checking the domain and search lines from resolv.conf for domains ending with .local. If so, treat this as a .local in unicast DNS case. Presumably if people have set up unicast .local domains they also specify them in the DNS search domains. A check like this would also have the big advantage that a couple of superfluous DNS queries (which might timeout, ...) can be skipped in many cases. Lennart -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages avahi-daemon depends on: ii adduser 3.103 Add and remove users and groups ii dbus 1.1.1-3simple interprocess messaging syst ii libavahi-common3 0.6.19-2 Avahi common library ii libavahi-core50.6.19-2 Avahi's embeddable mDNS/DNS-SD lib ii libc6 2.6-2 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdaemon00.10-1 lightweight C library for daemons ii libdbus-1-3 1.1.1-3simple interprocess messaging syst ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii lsb-base 3.1-23.1 Linux Standard Base 3.1 init scrip Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-3 NSS module for Multicast DNS name -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
