This package tells one to add the following line to /etc/nsswitch.conf: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 When I did this I could resolve domain names in .local, but no other (like gentoo.org etc - "normal" domain names). I had to do this (remove [NOTFOUND=return]): hosts: files mdns4_minimal dns mdns4 Another thing is that when viewing this message via elog the quoted line is not even show, only this: * Add the appropriate mdns into the hosts line in /etc/nsswitch.conf * An example line looks like: * * If you want to perform mDNS lookups for domains other than the ones * ending in .local, add them to /etc/mdns.allow
Uh, the [NOTFOUND=return] is there on purpose and works perfectly fine, this change was requested by upstream in Bug 137191 removing it is definitely a bad idea since it will produce *exactly* what you are complaining about: # grep hosts /etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 # ping www.gentoo.org PING www.gentoo.org (209.177.148.228) 56(84) bytes of data. 64 bytes from wren.gentoo.org (209.177.148.228): icmp_seq=1 ttl=49 time=221 ms 64 bytes from wren.gentoo.org (209.177.148.228): icmp_seq=2 ttl=49 time=220 ms --- www.gentoo.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 220.052/220.544/221.036/0.492 ms # grep hosts /etc/nsswitch.conf hosts: files mdns4_minimal dns mdns4 # ping www.gentoo.org PING www.gentoo.org (209.177.148.229) 56(84) bytes of data. --- www.gentoo.org ping statistics --- 11 packets transmitted, 0 received, 100% packet loss, time 9999ms
I have different effects here. When I *have* [NOTFOUND=return] it does not resolve the name at all, just says "unknown host". Maybe the behaviour is different depending on the glibc version or some other package, I don't know. About bug 137191 - there is nowhere explicitly said that removing [NOTFOUND=return] would be a Very Bad Thing. There were many other changes in this bug, and it was over year ago - something could change. And one more thing: note that even in your case it does correctly resolve hostname in both cases. And the pings not returning should be independent of DNS resolver. So please reconsider just closing this bug as invalid or whatever, maybe a maintainer should have a look at it. I'm a user and following advice in einfo lead to not-so-desirable consequences. Then there's something wrong with einfo, okay? Maybe my solution wasn't right, but then something better should be proposed in the ebuild IMHO.
(In reply to comment #2) > I have different effects here. When I *have* [NOTFOUND=return] it does not > resolve the name at all, just says "unknown host". Maybe the behaviour is > different depending on the glibc version or some other package, I don't know. Please read the provided README file for information, mdns[46]_minimal *only* resolves stuff for .local. It's completely useless to try to use the stuff following mdns4_minimal in nsswitch.conf for .local - since it will not return anything else that the fact we already know, that something.local thing doesn't resolve. With files mdns4_minimal [NOTFOUND=return] dns mdns4, `getent hosts something.local` will look at /etc/hosts, then will ask avahi via nss-mdns and if it still doesn't resolve, then it will finish, because it doesn't exist. With files dns4_minimal dns mdns4 in /etc/nsswitch.conf, `getent hosts something.local` will look at /etc/hosts, then will ask avahi via nss-mdns and find that it doesn't exist, will continue to query DNS server which obviously won't produce anything useful for .local, and then will once again ask avahi to only find out once again that something.local doesn't resolve. Nice waste of time, imagine that you DNS is unreachable, it will be sitting there waiting for timeout. If you have problems with this [NOTFOUND=return] thing , then restart nscd if you are using it, and if it still doesn't work then post your glibc version and reopen the bug.
(In reply to comment #3) > Please read the provided README file for information, mdns[46]_minimal *only* > resolves stuff for .local. I know. > It's completely useless to try to use the stuff following mdns4_minimal in > nsswitch.conf for .local - since it will not return anything else that the fact > we already know, that something.local thing doesn't resolve. Yeah, but we might want to resolve something not-local, just regular dns. > With files mdns4_minimal [NOTFOUND=return] dns mdns4, `getent hosts > something.local` will look at /etc/hosts, then will ask avahi via nss-mdns and > if it still doesn't resolve, then it will finish, because it doesn't exist. Okay. > With files dns4_minimal dns mdns4 in /etc/nsswitch.conf, `getent hosts > something.local` will look at /etc/hosts, then will ask avahi via nss-mdns and > find that it doesn't exist, will continue to query DNS server which obviously > won't produce anything useful for .local, and then will once again ask avahi to > only find out once again that something.local doesn't resolve. Nice waste of > time, imagine that you DNS is unreachable, it will be sitting there waiting for > timeout. For .local domains it would be a waste of time, but not for regular ones, like .org etc which are handled by normal dns servers. > If you have problems with this [NOTFOUND=return] thing , then restart nscd if > you are using it, and if it still doesn't work then post your glibc version and > reopen the bug. I'm not using nscd, and here is info about my glibc: GNU C Library stable release version 2.6.1, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.1.2 (Gentoo 4.1.2 p1.0.2). Compiled on a Linux >>2.6.22-gentoo-r8<< system on 2007-11-23. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1.1 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.
(In reply to comment #4) > For .local domains it would be a waste of time, but not for regular ones, like > .org etc which are handled by normal dns servers. You entirely missed the point. mdns4_minimal doesn't give a damn about anything but .local; so sorry but I fail to see what's your problem here. Post the getent output and your entire avahi/mdns configuration here because it doesn't any make sense.
(In reply to comment #5) > Post the > getent output and your entire avahi/mdns configuration here because it doesn't > any make sense. When the host is found, the getent output is standard, and when not found it's empty. /etc/mdns.allow: # mdns.allow: .local. .local Avahi - all defaults, nothing changed, version 0.6.19-r2 Interesting thing, but when I stop avahi, normal addresses like gentoo.org work fine even with [NOTFOUND=return] (but then mdns addresses don't get resolved at all). And vice versa: I start avahi, and with [NOTFOUND=return] mdns works fine, normal dns - not.
I'm getting exactly the same as the original reporter (ph) is getting. If /etc/nsswitch.conf has the line as recommended: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 Then any lookup that requires a *DNS* lookup - ie: for random external names like, oh, www.gentoo.org - fails to resolve. If [NOTFOUND=return] is removed, it works, but it takes a long time to resolve DNS names. nscd doesn't seem to affect this. It wasn't running before, and starting it doesn't make any difference. An Ubuntu (Hardy Beta) machine in the same network with the same hosts line in /etc/nsswitch.conf works perfectly. It's the out-of-the-box configuration. nb: It might be nice if sys-auth/nss-mdns is made a dependency of something (like avahi). My first problem was that mdns addresses were silently failing to resolve because that had not been installed. It wasn't obvious when all the configuration looked right. :-) I wonder if my pathological inclusion of ACCEPT_KEYWORDS="~*" is a factor? :-) mab ~ # emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r2, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ Timestamp of tree: Thu, 27 Mar 2008 09:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.5.1-r5 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64 ~*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.virginmedia.com/ " LINGUAS="en en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/mozilla" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl acpi amd64 apache2 avahi bash-completion berkdb bonjour bzip2 cli cracklib crypt dbus dri fontconfig fortran gdbm glitz gnome gpm gtk hal iconv ipv6 isdnlog java java5 jpeg libnotify midi mmx mudflap ncurses nls nptl nptlonly nsplugin opengl openmp pam pcre perl png pppd python readline reflection session spl sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode vim-syntax vorbis xcomposite xorg xulrunner zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="prefork" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia fbdev nv vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Same problem for me, both stable x86 and amd64 profiles.
Moving to maintainer-needed since compnerd left Gentoo (#71985).
This just started happening again for me, on a more recent installation of Gentoo. As before, nsswitch.conf has: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 ... as recommended. .local addresses *are* resolving, but non-local ones aren't. But... something interesting. This was working up until yesterday, but yesterday I switched out my router from a zeroshell box to an Airport Express (and got all my bandwidth back, rather than a tenth of it or less, so please don't ask me to switch back!) I'm not sure why it's relevant, but it's a pretty strong correlation. The Airport Express does seem to be doing its DHCP/DNS duties properly though, ie: the Gentoo box correctly gets the router's internal IP in its /etc/resolv.conf and issuing DNS queries using host works fine. ie: mab ~ # host www.gentoo.org www.gentoo.org has address 89.16.167.134 www.gentoo.org has address 209.177.148.229 www.gentoo.org has address 209.177.148.228 www.gentoo.org has address 89.16.167.134 mab ~ # ping www.gentoo.org ping: unknown host www.gentoo.org mab ~ # This time, sys-auth/nss-mdns is already installed. Thinking about it, this looks completely logical if lookups are supposed to return after trying files and mdns4_minimal... I guess I just never understood the [NOTFOUND=return] thing. What's the point of having anything after it? Oh, as before, all Macs, iPhones, Ubuntu boxes on the network are still resolving just fine. This is just happening to Gentoo. And the only difference between the Gentoo /etc/avahi/avahi-daemon.conf and one on an ubuntu Jaunty box (which is resolving fine) is that this line is commented out on the Ubuntu box: browse-domains=0pointer.de, zeroconf.org
(In reply to comment #10) > But... something interesting. This was working up until yesterday, but > yesterday I switched out my router from a zeroshell box to an Airport Express Correction, Airport Extreme, firmware version 7.4.2.
SOLVED for me..., sort of. Year and a half older, that bit wiser... In the DHCP configuration of the Airport Extreme I had set the domain to "local". So the line "domain local" appeared in the Gentoo box's /etc/resolv.conf. Removing that line manually, or more permanently, changing the domain field in the Airport Express (eg in my case to "bogus"), then renewing the DHCP lease, seems to have solved the problem. :-) Of course, the Ubuntu boxes and the Macs had also got "domain local" in their /etc/resolv.conf, but they didn't seem to mind... Something about Gentoo *minds* about this. I wouldn't be surprised if it's just a setting or a USE flag somewhere, but it would be good to know what it is.
I too am (surprisingly) encountering this problem. I have never had a problem resolving IPs on my laptop, even when I took it to work at my previous job. But then I took my laptop to my *new* job and addresses don't resolve (this is on the wire btw). At my new job "search domain.local" is added to resolv.conf. This seems to be ok for the ubuntu clients that we use at work, but not for my Gentoo laptop. I'm not sure if this is a configuation issue. The ubuntu boxes seem to be using dhclient and I'm using dhcpcd. I'll try switching to dhclient to see if that helps.
Yeah, same result whether I use dhcpcd or dhclient.
I think, the whole problem is the nss-mdns library does not conform the linux resolv.conf man page. Man page describes how the resolver handles domains listed by search and domain options: "Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found". It means that "search" and "domain" domains are not appended to FQDN, only to hostnames without the domain (with less than 1 dot). But the nss-mdns library appends these domains to all hostnames (in fact hostnames not ending with dot), therefore resolving of FQDN always fails.
Created attachment 218027 [details, diff] Proposed quick patch. This is proposed quick patch to allow coexistence of dns and mdns resolver with search or domain option in resolv.conf set to local (or anything ending with local). This is not a full solution, it does not implement entire "options ndots:n" resolv.conf logic.
Please fix this bug. I wasted 2hrs of my time on it today. It only misbehaves when "search local" is set in resolv.conf, but this could easily be done by a DHCP server or user. One of two things need to happen: 1. remove "--enable-search-domains" from the config. This causes names without domains to be sent to upstream servers when "search local" is set. Broken behavior, but at least it doesn't break all DNS resolution. 2. Apply a version of the patch attached that takes ndots: into account. I've applied it in my environment since I don't use ndots: and it seems to work fine.
Confirming the problem of comment #12, agreeing to the solution of comment #17. Please add IUSE=search-domains to toggle the --enable-search-domains flag.
I do not think the patch from comment #16 is correct: --- man 5 resolv.conf (sys-apps/man-pages-3.32) --- options ndots:n sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried **first** as an absolute name **before** any search list elements are appended to it. The value for this option is silently capped to 15. --- Emphasis (**) by me. I read that as: The domains given in the "search" line are *always* looked up, whether there are dots in the name or not. If you want to respect that, nss-mdns will always be useless in environments where domain=local. Hence I again propose adding IUSE=search-domains.
See bug #159798 comment #3 for another explanation why this flag should be added: > The project page says [NEWS for 0.9]: > > It created a lot of problems and was never recommended anyway. > > You may reenable this functionality by passing > > --enable-search-domains.
Created attachment 261959 [details, diff] Another approach at solving the problem Patch (almost) as sent to Lennart Poettering (upstream maintainer).
Created attachment 262013 [details, diff] Smaller patch This patch is less invasive, touching only the configure phase. Pushed as 70bcfbb2d6eba47f832d2780f6833242b3f6fc13 for sys-auth/nss-mdns-0.10-r1 into kde-overlay. Sent to Lennart Poettering, too. Keywords += InOverlay
http://avahi.org/wiki/AvahiAndUnicastDotLocal
Created attachment 289723 [details, diff] nss-mdns ebuild patch it adds USE search-domains. (In reply to comment #17) > Please fix this bug. I wasted 2hrs of my time on it today. It only misbehaves > when "search local" is set in resolv.conf, but this could easily be done by a > DHCP server or user. One of two things need to happen: > 1. remove "--enable-search-domains" from the config. This causes names without > domains to be sent to upstream servers when "search local" is set. Broken > behavior, but at least it doesn't break all DNS resolution. > 2. Apply a version of the patch attached that takes ndots: into account. I've > applied it in my environment since I don't use ndots: and it seems to work > fine. I have being messing about with bug for 2 days. I did debugged this bug over a year ago and fixed it in my overlay but I ran into it again with a new install. Anyway here is the clean patch.
+*nss-mdns-0.10-r1 (11 Feb 2012) + + 11 Feb 2012; Pacho Ramos <pacho@gentoo.org> + +files/nss-mdns-0.10-avahi-socket.patch, +nss-mdns-0.10-r1.ebuild, + -nss-mdns-0.8.ebuild, -nss-mdns-0.9-r1.ebuild, metadata.xml: + Make search-domains optional (bug #201948 by Jonathan Barnard, Dennis + Schridde, Paweł Hajdan, Jr. and many others), also fix bug #226823 by + flameeyes. Drop old. +
