Debian Bug report logs - #414569
avahi-daemon: delay on resolving IP addresses when mdns is specified in /etc/nsswitch.conf

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <ms@teamix.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: avahi-daemon: delay on resolving IP addresses when mdns is specified in /etc/nsswitch.conf

Date: Mon, 12 Mar 2007 16:57:08 +0100

Package: avahi-daemon
Version: 0.6.16-2
Severity: critical

Today I spent 5 hours or more for debugging a problem with slowness of
almost all running applications. I first found that IMAP access with
KMail was unusable slow, even after I installed dovecot locally. ssh and
most network related commands took 5 seconds delay after being started
before anything happened.

Well finally I found it times out on a request to resolve an IP address
with avahi. I stopped avahi and ssh worked instantly and IMAP access via
KMail accelerated immediately.

I started avahi-daemon again and the delays occured again.

I found that instead of stopping avahi-daemon I could also change
/etc/nsswitch.conf by removing any reference to mdns:

#hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
hosts:          files dns

This happened on a NFS based workstation with Debian Etch. And then
after an update to second workstation it happened also there. However I
am not sure which package update triggered this problem (see package
list below).

I am setting this to critical as it makes a NFS based network
workstation next to unusable. Feel free to lower the priority as you see
fit. Maybe it just happened here. But if not it IMHO should be fixed
before Etch release.

Excerpt of strace to demonstrate where the delays happen: 

ms@mango:~> strace ssh
execve("/usr/bin/ssh", ["ssh"], [/* 31 vars */]) = 0
uname({sys="Linux", node="mango", ...}) = 0
brk(0)                                  = 0x808a000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fab000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=115326, ...}) = 0
[...]

open("/etc/ld.so.cache", O_RDONLY)      = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=115326, ...}) = 0
mmap2(NULL, 115326, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb796f000
close(4)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
directory)
open("/lib/libnss_mdns4.so.2", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\t\0\000"...,
512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size=7208, ...}) = 0
mmap2(NULL, 10164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0)
= 0xb796c000
mmap2(0xb796e000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xb796e000
close(4)                                = 0
munmap(0xb796f000, 115326)              = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 4
fcntl64(4, F_GETFD)                     = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
connect(4, {sa_family=AF_FILE, path="/var/run/avahi-daemon/socket"},
110) = 0
fcntl64(4, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(4, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f8f000
_llseek(4, 0, 0xbfc67f44, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(4, "RESOLVE-ADDRESS 172.21.242.9\n", 29) = 29
read(4,

Here is hangs for about 5 seconds, maybe a bit more... then it goes on
with:

"-15 Timeout reached\n", 1024)  = 20
close(4)                                = 0
munmap(0xb7f8f000, 4096)                = 0
uname({sys="Linux", node="mango", ...}) = 0
time(NULL)                              = 1173712863
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14
time(NULL)                              = 1173712863
select(1024, [3], [], NULL, {30, 0})    = 1 (in [3], left {30, 0})
read(3, "0\f\2\1\1a\7\n", 8)            = 8
read(3, "\1\0\4\0\4\0", 6)              = 6
time(NULL)                              = 1173712863
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(45161),
sin_addr=inet_addr("172.21.123.1")}, [16]) = 0
getpeername(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("172.21.242.9")}, [16]) = 0
time([1173712863])                      = 1173712863
time(NULL)                              = 1173712863
write(3, "0\201\304\2\1\2c\201\276\4\20dc=teamix,dc=net\n\1\2\n\1"...,
199) = 199
select(1024, [3], [], NULL, NULL)       = 1 (in [3])
read(3, "0\202\1H\2\1\2d", 8)           = 8
read(3, "\202\1A\4!uid=ms,ou=people,dc=teamix,"..., 324) = 324
select(1024, [3], [], NULL, NULL)       = 1 (in [3])
read(3, "0\f\2\1\2e\7\n", 8)            = 8
read(3, "\1\0\4\0\4\0", 6)              = 6
time(NULL)                              = 1173712863
time([1173712863])                      = 1173712863
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
umask(022)                              = 022
write(2, "usage: ssh [-1246AaCfgKkMNnqsTtV"..., 407usage: ssh
[-1246AaCfgKkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-i identity_file] [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-w tunnel:tunnel] [user@]hostname [command]
) = 407
exit_group(255)                         = ?
Process 8977 detached


List of packages updated recently:
mango:~# ls -lt /var/cache/apt/archives | head -n50
insgesamt 48660
drwxr-xr-x 2 root root       6 2007-03-12 14:13 partial
-rw-r--r-- 1 root root  567300 2007-03-09 03:17
libx11-6_2%3a1.0.3-6_i386.deb
-rw-r--r-- 1 root root  157038 2007-03-09 03:17
libx11-data_2%3a1.0.3-6_all.deb
-rw-r--r-- 1 root root 1268796 2007-03-09 03:17
libx11-dev_2%3a1.0.3-6_i386.deb
-rw-r--r-- 1 root root 1527904 2007-03-08 18:47
libavcodec0d_0.cvs20060823-7_i386.deb
-rw-r--r-- 1 root root   36862 2007-03-08 18:47
libpostproc0d_0.cvs20060823-7_i386.deb
-rw-r--r-- 1 root root  132350 2007-03-07 19:02
libvisual-0.4-0_0.4.0-1.1_i386.deb
-rw-r--r-- 1 root root 9039658 2007-03-07 11:02
iceweasel_2.0.0.2+dfsg-3_i386.deb
-rw-r--r-- 1 root root   80258 2007-03-07 11:02
iceweasel-gnome-support_2.0.0.2+dfsg-3_i386.deb
-rw-r--r-- 1 root root   46278 2007-03-07 03:47
comerr-dev_2.1-1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   86822 2007-03-07 03:47
e2fslibs_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root  596094 2007-03-07 03:47
e2fsprogs_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   43370 2007-03-07 03:47
libblkid1_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   31114 2007-03-07 03:47
libcomerr2_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   37158 2007-03-07 03:47
libss2_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   33418 2007-03-07 03:47
libuuid1_1.39+1.40-WIP-2006.11.14+dfsg-2_i386.deb
-rw-r--r-- 1 root root   18116 2007-03-06 19:17
libglu1-xorg-dev_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root  334288 2007-03-06 19:17
x11-common_1%3a7.1.0-15_i386.deb
-rw-r--r-- 1 root root   18110 2007-03-06 19:17
xlibmesa-dri_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18112 2007-03-06 19:17
xlibmesa-gl_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18122 2007-03-06 19:17
xlibmesa-gl-dev_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18134 2007-03-06 19:17
xlibs-data_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18248 2007-03-06 19:17
xlibs-static-dev_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18384 2007-03-06 19:17
xorg_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root  442862 2007-03-06 19:17
xserver-xorg_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18188 2007-03-06 19:17
xserver-xorg-input-all_1%3a7.1.0-15_i386.deb
-rw-r--r-- 1 root root   18326 2007-03-06 19:17
xserver-xorg-video-all_1%3a7.1.0-15_i386.deb
-rw-r--r-- 1 root root   18160 2007-03-06 19:17
x-window-system_1%3a7.1.0-15_all.deb
-rw-r--r-- 1 root root   18170 2007-03-06 19:17
x-window-system-core_1%3a7.1.0-15_all.deb
-rw-r----- 1 root root       0 2007-03-06 14:14 lock
-rw-r--r-- 1 root root   82452 2007-03-06 12:47
libgksu2-0_2.0.3-7_i386.deb
-rw-r--r-- 1 root root  302844 2007-03-05 20:32 tcpdump_3.9.5-2_i386.deb
-rw-r--r-- 1 root root  616078 2007-03-05 18:32
openssh-client_1%3a4.3p2-9_i386.deb
-rw-r--r-- 1 root root  221646 2007-03-05 18:32
openssh-server_1%3a4.3p2-9_i386.deb
-rw-r--r-- 1 root root   82520 2007-03-05 18:32
libsensors3_1%3a2.10.1-3_i386.deb
-rw-r--r-- 1 root root  501988 2007-03-05 18:32
lm-sensors_1%3a2.10.1-3_i386.deb
-rw-r--r-- 1 root root    1054 2007-03-05 17:32 ssh_1%3a4.3p2-9_all.deb
-rw-r--r-- 1 root root   60830 2007-03-04 22:47
gtk2-engines-pixbuf_2.8.20-7_i386.deb
-rw-r--r-- 1 root root 1620154 2007-03-04 22:47
libgtk2.0-0_2.8.20-7_i386.deb
-rw-r--r-- 1 root root    7168 2007-03-04 22:47
libgtk2.0-bin_2.8.20-7_all.deb
-rw-r--r-- 1 root root 3755056 2007-03-04 22:47
libgtk2.0-common_2.8.20-7_all.deb
-rw-r--r-- 1 root root  334388 2007-03-04 20:32 ppp_2.4.4rel-7_i386.deb
-rw-r--r-- 1 root root 5497542 2007-03-04 16:02 ekiga_2.0.3-4_i386.deb
-rw-r--r-- 1 root root  142134 2007-03-04 16:02
gnomemeeting_2.0.3-4_all.deb
-rw-r--r-- 1 root root   76044 2007-03-04 13:32
libpth20_2.0.7-6_i386.deb
-rw-r--r-- 1 root root   62356 2007-03-03 22:17
libvolume-id0_0.105-3_i386.deb
-rw-r--r-- 1 root root  263126 2007-03-03 22:17 udev_0.105-3_i386.deb
-rw-r--r-- 1 root root  799252 2007-02-27 20:02
login_1%3a4.0.18.1-7_i386.deb
-rw-r--r-- 1 root root  789268 2007-02-27 20:02
passwd_1%3a4.0.18.1-7_i386.deb



-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.7-workstation-sws2-2.2.7
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages avahi-daemon depends on:
ii  adduser                     3.102        Add and remove users and groups
ii  dbus                        1.0.2-1      simple interprocess messaging syst
ii  libavahi-common3            0.6.16-2     Avahi common library
ii  libavahi-core4              0.6.16-2     Avahi's embeddable mDNS/DNS-SD lib
ii  libc6                       2.3.6.ds1-13 GNU C Library: Shared libraries
ii  libcap1                     1:1.10-14    support for getting/setting POSIX.
ii  libdaemon0                  0.10-1       lightweight C library for daemons
ii  libdbus-1-3                 1.0.2-1      simple interprocess messaging syst
ii  libexpat1                   1.95.8-3.4   XML parsing C library - runtime li

Versions of packages avahi-daemon recommends:
ii  libnss-mdns                   0.9-0.2    NSS module for Multicast DNS name 

-- no debconf information

Message #10 received at 414569@bugs.debian.org (full text, mbox, reply):

From: sjoerd@spring.luon.net (Sjoerd Simons)

To: Martin Steigerwald <ms@teamix.de>, 414569@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#414569: avahi-daemon: delay on resolving IP addresses when mdns is specified in /etc/nsswitch.conf

Date: Mon, 12 Mar 2007 18:00:18 +0100

severity 414569 normal
thanks,

On Mon, Mar 12, 2007 at 04:57:08PM +0100, Martin Steigerwald wrote:
> Today I spent 5 hours or more for debugging a problem with slowness of
> almost all running applications. I first found that IMAP access with
> KMail was unusable slow, even after I installed dovecot locally. ssh and
> most network related commands took 5 seconds delay after being started
> before anything happened.
> 
> Well finally I found it times out on a request to resolve an IP address
> with avahi. I stopped avahi and ssh worked instantly and IMAP access via
> KMail accelerated immediately.
> 
> I started avahi-daemon again and the delays occured again.
> 
> I found that instead of stopping avahi-daemon I could also change
> /etc/nsswitch.conf by removing any reference to mdns:
> 
> #hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
> hosts:          files dns
> 
> This happened on a NFS based workstation with Debian Etch. And then
> after an update to second workstation it happened also there. However I
> am not sure which package update triggered this problem (see package
> list below).
> 
> I am setting this to critical as it makes a NFS based network
> workstation next to unusable. Feel free to lower the priority as you see
> fit. Maybe it just happened here. But if not it IMHO should be fixed
> before Etch release.

It looks like you don't have proper reverse resolving setup. So if an
application wants to do reverse resolving on your network, it ends up using the
mdns4 in your nsswitch. Which in turn triggers avahi to try and resolve the
ip. If there is nobody that can answer the lookup on mdns, the request times
out after a while and thus the failure is reported to the app..  Now what your
seeing is that the timeout is (and afaik is supposed to be) a few seconds.

I'm not sure why this makes your NFS based workstation unusable.. Surely NFS
shouldn't do reverse lookups that often.

Also i'm not sure if this is really a bug.. An unsuccessfull rev. dns lookup on
mdns takes a few seconds by design, so not much we can do about this. For your
local setup you can either add proper rev. resolving to your network or disable
the final mdns fallback so it only ever uses mdns4_minimal.

  Sjoerd
-- 
Life can be so tragic -- you're here today and here tomorrow.

Message #17 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <ms@teamix.de>

To: 414569@bugs.debian.org

Subject: Reverse lookup for said host is not set up

Date: Tue, 13 Mar 2007 09:59:31 +0100

Hello!

Reverse lookup for said the host in the strace - our ldap server - is not set 
up.

ms@mango:~> host 172.21.242.9
Host 9.242.21.172.in-addr.arpa not found: 3(NXDOMAIN)

It tells so immediately. 

To my knowledge there is no strict requirement that an LDAP or any other hosts 
in a local network needs a reverse lookup set up.

I imagine there may be lots of networks where reverse lookup is not defined 
for some hosts, my network at home doesn't even have a DNS server.

At least I do not get whether avahi tries to find out about the same IP 
address again and again. Since the workstation uses LDAP I think that IP 
reverse lookup for that IP address is queried for very often. The "strace 
ssh" case was repeatable after a second. It shouldn't try to find out about 
that IP address that often IMHO. If it isn't known it should wait some time 
before it tries again. That would be an avahi-daemon issue.

Added to that I would be more reluctant to add an option to nsswitch that 
delays reverse lookups where the DNS server returns not found in a fraction 
of a second by 5 seconds or more. Its the postinst script of the package 
libnss-mdns that does it:

---------------------------------------------------------------------
    perl -i -pe '
        sub insert {
            # this also splits on tab
            my @bits=split(" ", shift);
            # do not break configuration if the "hosts" line already 
references
            # mdns
            if (grep { $_ eq "mdns4_minimal" || $_ eq "mdns4"
                || $_ eq "mdns" || $_ eq "mdns_minimal"
                || $_ eq "mdns6" || $_ eq "mdns6_minimal"} @bits) {
                return join " ", @bits;
            }
            # change "dns" into "mdns4_minimal [NOTFOUND=return] dns mdns4"
            return join " ", map {
                $_ eq "dns" ? ("mdns4_minimal","[NOTFOUND=return]",
$_,"mdns4") : $_
            } @bits;
        }
        s/^(hosts:\s+)(.*)/$1.insert($2)/e;
    ' /etc/nsswitch.conf
---------------------------------------------------------------------

I cannot remember that it asked me whether I like to do these changes. It 
maybe tries to do these changes again when the package is updated.

I recommend that "mdns4_minimal" is added by default - I doesn't create the 
timeout as I tested today -, but "mdns4" after dns lookup is not without 
asking the user first. That would be a libnss-mdns issue.

About NFS I agree with you, it likely wasn't NFS, it was the LDAP lookups and 
possibly other server IP address reverse lookups I think.

Regards,
-- 
Martin Steigerwald
Trainer / Consultant / Systems Engineer

team(ix) GmbH
Solide IT-Infrastruktur
Südwestpark 35
90449 Nürnberg

fon:   +49 (911) 30999- 0
fax:   +49 (911) 30999-99
mail:  ms@teamix.de
web:   http://www.teamix.de
vcf:   http://www.teamix.de/vcf/ms.vcf
gpg:   19E3 8D42 896F D004 08AC
       A0CA 1E10 C593 0399 AE90

Amtsgericht Nürnberg, HRB 18320
Geschäftsführer: Oliver Kügow, Richard Müller

Message #22 received at 414569@bugs.debian.org (full text, mbox, reply):

From: sjoerd@spring.luon.net (Sjoerd Simons)

To: Martin Steigerwald <ms@teamix.de>, 414569@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#414569: Reverse lookup for said host is not set up

Date: Tue, 13 Mar 2007 11:40:23 +0100

reassign 414569 nss-mdns
thanks,

On Tue, Mar 13, 2007 at 09:59:31AM +0100, Martin Steigerwald wrote:
> 
> Hello!
> 
> Reverse lookup for said the host in the strace - our ldap server - is not set 
> up.
> 
> ms@mango:~> host 172.21.242.9
> Host 9.242.21.172.in-addr.arpa not found: 3(NXDOMAIN)
> 
> It tells so immediately. 
> 
> To my knowledge there is no strict requirement that an LDAP or any other
> hosts in a local network needs a reverse lookup set up.
> 
> I imagine there may be lots of networks where reverse lookup is not defined 
> for some hosts, my network at home doesn't even have a DNS server.
> 
> At least I do not get whether avahi tries to find out about the same IP 
> address again and again. Since the workstation uses LDAP I think that IP 
> reverse lookup for that IP address is queried for very often. The "strace 
> ssh" case was repeatable after a second. It shouldn't try to find out about 
> that IP address that often IMHO. If it isn't known it should wait some time 
> before it tries again. That would be an avahi-daemon issue.
> 
> Added to that I would be more reluctant to add an option to nsswitch that 
> delays reverse lookups where the DNS server returns not found in a fraction 
> of a second by 5 seconds or more. 

Avahi doesn't query the dns server for the reverse lookup, but uses Multicast
DNS.. Because that's what avahi is, a multicast dns daemon :)..  I'll ask
upstream why avahi doesn't cache negative lookups for some time.. But even if
it did it wouldn't really solve your problem, as the timeout will keep occuring
from time to time.

> Its the postinst script of the package libnss-mdns that does it:

> I cannot remember that it asked me whether I like to do these changes. It 
> maybe tries to do these changes again when the package is updated.

Correct, it configures the system automatically for mdns to work..  

> I recommend that "mdns4_minimal" is added by default - I doesn't create the 
> timeout as I tested today -, but "mdns4" after dns lookup is not without 
> asking the user first. That would be a libnss-mdns issue.

Right, mdns4_minimal only does actual checking for certain names, that's why it
doesn't time-out for you.. It's not actually doing anything.

I'm reassigning this bug to nss-mdns.. I need to discuss with some others what
to do about this.. Your suggestion of not adding the final mdns fallback does
make sense for your network, but it will break some functionality on others..
(Where mdns can actually rev. resolv the ip because the other machine also uses
mdns..)


  Sjoerd
-- 
The truth is rarely pure, and never simple.
		-- Oscar Wilde

Message #29 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Martin Steigerwald <ms@teamix.de>

To: Sjoerd Simons <sjoerd@spring.luon.net>

Cc: 414569@bugs.debian.org

Subject: Re: [Pkg-utopia-maintainers] Bug#414569: Reverse lookup for said host is not set up

Date: Wed, 14 Mar 2007 09:36:19 +0100

Am Dienstag, 13. März 2007 11:40 schrieb Sjoerd Simons:


> > Added to that I would be more reluctant to add an option to nsswitch that
> > delays reverse lookups where the DNS server returns not found in a
> > fraction of a second by 5 seconds or more.
>
> Avahi doesn't query the dns server for the reverse lookup, but uses
> Multicast DNS.. Because that's what avahi is, a multicast dns daemon :).. 

Hello Sjoerd,

I know that. And sure as stated in nsswitch.conf mdns is asked afterwards and 
thus observed behavior is to be expected. I didn't think this to its logical 
end.

> I'll ask upstream why avahi doesn't cache negative lookups for some time..
> But even if it did it wouldn't really solve your problem, as the timeout
> will keep occuring from time to time.

I think it would make the critical difference between unusable and quite 
usable if the timeout would be 5 minutes or so. Actually I do not see much 
other alternatives if one wants to use mdns in a network with incomplete 
reverse DNS configuration. For us right now its no problem to go without mdns 
and we also can complete the reverse DNS configuration.

But caching negative results also has a negative impact on the mdns 
functionality I think. Imagine you try to reach a host that you forgot to 
connect to the network, then you connect it, and you have to wait for the 
negative lookup cache entry timeout before you can get a positive result from 
Avahi, unless Avahi passively gets notice of the new host.

> I'm reassigning this bug to nss-mdns.. I need to discuss with some others
> what to do about this.. Your suggestion of not adding the final mdns
> fallback does make sense for your network, but it will break some
> functionality on others.. (Where mdns can actually rev. resolv the ip
> because the other machine also uses mdns..)

Thats the problem here. While I agree that having complete reverse DNS 
configuration is generally a good idea and we recently installed a tool to 
ensure it in the future, the default configuration of libnss-mdns may make 
network workstations and possibly servers quite unusable in such networks and 
I bet there might be quite  some out there. And to my knowledge a complete 
reverse DNS configuration is not a strict requirement. If thats really the 
case libnss-mdns by default places a requirement upon the network 
configuration that hasn't been there before.

OTOH not having it configured that way breaks mdns functionality on other 
networks.

The only other compromise than timeout for negative lookups I can think of is 
to have avahi-daemon running in passive mode. I do not know enough about how 
multicast DNS works to say whether thats possible at all. In this mode 
avahi-daemon would collect mdns announcements (if mdns capable machines 
announce themselves at all which I do not know) in a cache and will serve 
requests from this cache. If an entry is not in the cache it would return 
immediately. 

Regards,
-- 
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Message #34 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Trent Lloyd <lathiat@bur.st>

To: Martin Steigerwald <ms@teamix.de>, 414569@bugs.debian.org

Cc: Sjoerd Simons <sjoerd@spring.luon.net>

Subject: Re: Bug#414569: [Pkg-utopia-maintainers] Bug#414569: Reverse lookup for said host is not set up

Date: Wed, 14 Mar 2007 18:41:46 +0900

Howdy,

On Wed, Mar 14, 2007 at 09:36:19AM +0100, Martin Steigerwald wrote:
> Am Dienstag, 13. M?rz 2007 11:40 schrieb Sjoerd Simons:
> 
> 
> > > Added to that I would be more reluctant to add an option to nsswitch that
> > > delays reverse lookups where the DNS server returns not found in a
> > > fraction of a second by 5 seconds or more.
> >
> > Avahi doesn't query the dns server for the reverse lookup, but uses
> > Multicast DNS.. Because that's what avahi is, a multicast dns daemon :).. 
> 
> Hello Sjoerd,
> 
> I know that. And sure as stated in nsswitch.conf mdns is asked afterwards and 
> thus observed behavior is to be expected. I didn't think this to its logical 
> end.
> 
> > I'll ask upstream why avahi doesn't cache negative lookups for some time..
> > But even if it did it wouldn't really solve your problem, as the timeout
> > will keep occuring from time to time.
> 
> I think it would make the critical difference between unusable and quite 
> usable if the timeout would be 5 minutes or so. Actually I do not see much 
> other alternatives if one wants to use mdns in a network with incomplete 
> reverse DNS configuration. For us right now its no problem to go without mdns 
> and we also can complete the reverse DNS configuration.
> 
> But caching negative results also has a negative impact on the mdns 
> functionality I think. Imagine you try to reach a host that you forgot to 
> connect to the network, then you connect it, and you have to wait for the 
> negative lookup cache entry timeout before you can get a positive result from 
> Avahi, unless Avahi passively gets notice of the new host.
> 
> > I'm reassigning this bug to nss-mdns.. I need to discuss with some others
> > what to do about this.. Your suggestion of not adding the final mdns
> > fallback does make sense for your network, but it will break some
> > functionality on others.. (Where mdns can actually rev. resolv the ip
> > because the other machine also uses mdns..)
> 
> Thats the problem here. While I agree that having complete reverse DNS 
> configuration is generally a good idea and we recently installed a tool to 
> ensure it in the future, the default configuration of libnss-mdns may make 
> network workstations and possibly servers quite unusable in such networks and 
> I bet there might be quite  some out there. And to my knowledge a complete 
> reverse DNS configuration is not a strict requirement. If thats really the 
> case libnss-mdns by default places a requirement upon the network 
> configuration that hasn't been there before.
> 
> OTOH not having it configured that way breaks mdns functionality on other 
> networks.
> 
> The only other compromise than timeout for negative lookups I can think of is 
> to have avahi-daemon running in passive mode. I do not know enough about how 
> multicast DNS works to say whether thats possible at all. In this mode 
> avahi-daemon would collect mdns announcements (if mdns capable machines 
> announce themselves at all which I do not know) in a cache and will serve 
> requests from this cache. If an entry is not in the cache it would return 
> immediately. 

Avahi has an ability to return results and then say thats 'the end of my
cache' or 'thats all the results i think your going to get for the
minute' although the way the simple API nss-mdns uses is different.

in short, technically this is possible, practically not yet
implemented.

Trent

> 
> Regards,
> -- 
> Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
> gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
> 

Message #39 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Chris Gilbert <disciple3d@disciple3d.co.uk>

To: 414569@bugs.debian.org

Subject: Hmm...

Date: Fri, 12 Jun 2009 15:09:27 +0100

This bug is causing a lot of problems.  As the avahi-daemon is enabled  
by default, you need a great deal of knowledge to know what is going  
on here.  For instance, our Microsoft network in the office uses the  
popular .local pseudo domain.

When connected to the VPN:

ping server - Works fine
ping server.ourdomain.local - Times out.

When in the office, and on the local LAN, I can't resolve .local  
hostnames at all when using actual services (i.e. SSH, ping etc).

To compound things, lookups using dig, host or nslookup commands all  
work fine.  Thereby confusing me even further.

If I do:

sudo /etc/init.d/avahi-daemon stop

Magically, FQDN lookups work again.  It took me a long time to find  
this out :)

FQDN lookups on .local domains are essential to anyone who uses a  
Microsoft network.  And lots of people don't have reverse lookups  
configured for their local IP addresses - this is a very common  
problem.  I know, we probably should have, but if everything works  
properly, why change it?

For now, I'll just disable the daemon, but it would be nice for other  
people not to have to fall foul of this, since it's such basic  
functionality.


thanks,

Chris

Message #44 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Mike Crowe <mac@mcrowe.com>

To: 414569@bugs.debian.org

Subject: Confusion

Date: Thu, 23 Sep 2010 13:57:15 +0100

I think that there are separate problems here that are getting
intermingled in this bug report and others
(e.g. https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940 )

The particular variant that the original bug reporter appears to be
suffering from (and I happen to also be suffering from) is that even
if you have a DNS server that authoritatively claims that no reverse
mapping is available for a particular IP address mdns4 still times out
trying to find a name via Multicast DNS. It does this even if the IP
address is not even on the local network (I can imagine a situation
where this might actually be useful but I doubt it occurs in
practice.)

I was able to stop reverse lookups gettings as far as mdns4 in this
situation by changing /etc/nsswitch.conf to say:

 hosts: files mdns4_minimal [NOTFOUND=return] dns [NOTFOUND=return] mdns4

The idea is that if a definitive failure is returned by DNS then it
won't go on to try Multicast DNS. If DNS times out or is unconfigured
then Multicast DNS is tried (and may then go on to time out.)

This works for me (on lenny) in avoiding the timeout when the DNS
server responds with NXDOMAIN. In theory it should also support the
AutoIP ad-hoc network with no DNS server situation too but I can't
easily test that. It does break when there is a DNS server that
doesn't know about every host on the network but only for reverse
mapping so it may not be the end of the world.

I agree with Martin in message #29 and Trent in message #34 that the
only decent way to solve this is to rely on avahi to cache mDNS
information as hosts come and go and rely on that cache only for
reverse lookups. The answer will then always be (almost) instant.

Mike.

Message #49 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Andrew Bortz <abortz@cs.stanford.edu>

To: 414569@bugs.debian.org

Subject: Re: Confusion

Date: Wed, 9 Mar 2011 15:42:31 -0800

Mike's solution of changing the hosts line of /etc/nsswitch.conf to read:

  hosts: files mdns4_minimal [NOTFOUND=return] dns [NOTFOUND=return] mdns4

is exactly what I've been doing on all Avahi-enabled Linux machines
for some time now, and Debian should really pick up this patch, or
some variant. It does not solve the unicast .local lookups problem
that others are having, but since that is now relatively rare,
deprecated behavior, it should probably be solved as a configuration
switch in a different patch.

This patch _does_ solve the very common situation of long timeouts
attempting a reverse lookup on an IP address that does not have a
reverse record (any IP, not just local ones), without breaking lookups
for computers without any unicast DNS resolver (e.g. avahi-autoipd).
This patch will break multicast reverse lookups for IPs outside
169.254/16, but since those are a "bad idea" anyway, this is a
no-brainer IMO.

Sorry that I'm not familiar with the Debian dev process, but is there
someone currently assigned to this bug? The patch must be close to a
1-liner, so I can contribute it if necessary.

- Andrew

Message #54 received at 414569@bugs.debian.org (full text, mbox, reply):

From: Timo Jyrinki <timo.jyrinki@iki.fi>

To: 414569@bugs.debian.org

Subject: Re: Confusion

Date: Fri, 24 May 2013 09:09:39 +0300

Confirming that
-hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
+hosts:          files mdns4_minimal [NOTFOUND=return] dns
[NOTFOUND=return] mdns4

fixes the problem of slow connecting to my Debian machine over SSH in an
internal network.

-Timo

Message #59 received at 414569-close@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: 414569-close@bugs.debian.org

Subject: Bug#414569: fixed in nss-mdns 0.10-4

Date: Wed, 12 Jun 2013 10:19:21 +0000

Source: nss-mdns
Source-Version: 0.10-4

We believe that the bug you reported is fixed in the latest version of
nss-mdns, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 414569@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated nss-mdns package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 12 Jun 2013 09:57:13 +0100
Source: nss-mdns
Binary: libnss-mdns lib32nss-mdns
Architecture: source amd64
Version: 0.10-4
Distribution: experimental
Urgency: low
Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description: 
 lib32nss-mdns - NSS module for mDNS name resolution (transitional package)
 libnss-mdns - NSS module for Multicast DNS name resolution
Closes: 412714 414569 561622 686984 710232
Changes: 
 nss-mdns (0.10-4) experimental; urgency=low
 .
   * Add myself to Uploaders
   * Acknowledge NMUs
   * Remove 00_dns_unaligned_access.patch, already applied upstream in 0.10
   * Convert to 3.0 (quilt) format, with 01_ia64_alignment.patch applied
     as a patch by dpkg
   * Bring debhelper compat up to 9
   * Use dpkg's default.mk for architecture and hardening flags
   * Use dh and dh_autoreconf
   * Make libnss-mdns Multi-arch: same (Closes: #686984, #710232)
   * Switch lib32nss-mdns from a biarch package built on amd64 to a
     transitional package built on i386: this means users of wheezy's
     multiarch Wine packages, who already have i386 as a foreign
     architecture, should automatically get cross-graded from
     lib32nss-mdns:amd64 to lib32nss-mdns:i386 and hence to libnss-mdns:i386
   * Simplify build system now that there is only one "flavour"
   * debian/control: remove duplicate Section
   * Standards-Version: 3.9.4 (no further changes)
   * Run dh_install with --list-missing
   * Add gbp.conf
   * Add debian/source/local-options to unapply patches when built from git
   * On new installations, do not add "mdns4" to nsswitch.conf, only
     "mdns4_minimal [NOTFOUND=return]". This means we can't
     perform reverse DNS using mDNS for addresses outside 169.254.x.x and
     fe80::/10, but avoids a 5 second delay if such addresses do not
     have a PTR record in DNS (Closes: #412714, #414569, #561622 for
     new installations).
   * Document the alternative configuration with mdns4 in README.Debian
Checksums-Sha1: 
 96ec51391c406ac734cb30d91329b55329a3581b 1855 nss-mdns_0.10-4.dsc
 aaacc984af1d0f82bbc57d0f6fe33b182b85b924 9577 nss-mdns_0.10-4.debian.tar.gz
 0e4f5d4e0d2b5b311fc54e9fd0ac6b305c5c4516 27550 libnss-mdns_0.10-4_amd64.deb
Checksums-Sha256: 
 d135514ec3cb1988767cd27745ed2309a41803deb5145f4fcae778fcd123b316 1855 nss-mdns_0.10-4.dsc
 90489fdae46fbcb1245fda6743095ad4b28f0e582e3189a31ca19617a1792126 9577 nss-mdns_0.10-4.debian.tar.gz
 527b70716cf2d054c52382e43f047f334aae8f26c9a28accd4296477e8c674f3 27550 libnss-mdns_0.10-4_amd64.deb
Files: 
 8445563252f50cb982ae31bf8e542228 1855 admin optional nss-mdns_0.10-4.dsc
 ea61bf6a5c7e2d8492073803fd49ca02 9577 admin optional nss-mdns_0.10-4.debian.tar.gz
 cf8297551bd1607e8bf0124f1c6f9451 27550 admin optional libnss-mdns_0.10-4_amd64.deb

-----BEGIN PGP SIGNATURE-----

iQIVAwUBUbhDyU3o/ypjx8yQAQjSLA/+PbwYstIR+QS5M8zRL60/8Ll8ZA6JvU+G
T8dLEucVKbnw2cy9i+/zTF1UZMrwkYZFZla7S6+JUM829EOWwx1sPVv1dekEnUYW
IFBMYQCo9oW+61vB9UGjJQjXmwmPX/LYJLL3XCYtkqaqzKKVv6f0HMPb745UZ/N/
zq4Wrm/Ag1kImEixXsrJGzADz5+7EXBW0axzLEzhc42S1WEcxJajT3sCsk+MkE8M
K2k9gCyaJinXSwAeS7Sgud9jg9a5xZLl7qOBID9dIgMaKjV/DE8cKFGGP8rPnaj2
S2pUVfdWWxJvsaidjBhMkxzGL+s02h4qg+toFZOoYpo6BUi4pnGqp6DOFeazb/2g
Q3x3uVnE3QoGwPwbzTh7o6nxk3EkGMDsKPk/LdwJ/0ZkibXer09efUxRusmmCThl
qA5DdxR//TsKP8PpnQ+Pv+tlxAPKSsZbB2YUtmE78/x/ZBel23Kjp43GxuazFIpB
ANVr+mfj2aMG+feKYiI1CszmRLc21k39uDfrFQWn1Zxsq1F3TJYJjlgaZmVnrQuG
a3y+8fOPY0hBiU4Dz+W/oLZiNkGsHDVEj+cFJFH+MiC7cSQZFSfqAjHR8EqTg0y5
+8GGBuHshbAcfCE9urNS6XM7LbH2ZC36KmNPDsN1M2yzPEst/jMrHVPmgYHBoQv0
4l8wVievKs0=
=ncFB
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.