After upgrading to glibc-2.9_p20081201 seems like some hosts cannot be resolved by glibc resolver anymore (eg. using telnet or ssh commands): gringo@sun ~ $ ssh www.gentoo.org ssh: Could not resolve hostname www.gentoo.org: Name or service not known gringo@sun ~ $ ssh www.debian.org ssh: Could not resolve hostname www.debian.org: Name or service not known Some others can be resolved: gringo@sun ~ $ ssh -o ConnectTimeout=2 www.yahoo.com ssh: connect to host www.yahoo.com port 22: Connection timed out Host command succeeds as well: gringo@sun ~ $ host www.gentoo.org www.gentoo.org has address 209.177.148.229 www.gentoo.org has address 209.177.148.228 gringo@sun ~ $ host www.debian.org www.debian.org has address 194.109.137.218 www.debian.org mail is handled by 0 . To isolate the problem I copied my environment to other working machine (amd64) and tried to run ssh in chroot jail. It could not resolve names either although after replacing libc.so.6 and ld-linux.so.2 from that machine (glibc-2.6.1) it started working again. This would indicate that problem lies within glibc itself. Reproducible: Always Steps to Reproduce: 1. Upgrade glibc to 2.9_p20081201 2. Try to resolve www.gentoo.org or www.debian.org using glibc resolver Actual Results: Resolution will fail Expected Results: Resolution should succeed gringo@sun ~ $ emerge --info Portage 2.1.6 (default/linux/amd64/2008.0/desktop, gcc-4.3.2, glibc-2.9_p20081201-r0, 2.6.27-hh6 x86_64) ================================================================= System uname: Linux-2.6.27-hh6-x86_64-AMD_Phenom-tm-_9850_Quad-Core_Processor-with-glibc2.2.5 Timestamp of tree: Tue, 09 Dec 2008 18:15:01 +0000 app-shells/bash: 3.2_p48 dev-lang/python: 2.4.4-r13, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=amdfam10 -ftree-vectorize -fvect-cost-model -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=amdfam10 -ftree-vectorize -fvect-cost-model -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,now" LINGUAS="en pl" MAKEOPTS="-j5" 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/local/paludis/local /usr/local/paludis/extras" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde ldap libnotify mad midi mikmod mmx mp3 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode usb vorbis xml xorg xv 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 mmap_emul 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" CAMERAS="canon" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en pl" USERLAND="GNU" VIDEO_CARDS="fglrx v4l" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This is probably the DNS bug that was mentioned on libc-alpha. Reassigning to toolchain. Also tracked at: http://bugs.archlinux.org/task/12215 FWIW.
I am having the same problem but it seems like if you turn off ipv6 it works (possible workaround for now). Try using ssh -4 <hostname here>
(In reply to comment #2) > I am having the same problem but it seems like if you turn off ipv6 it works > (possible workaround for now). Try using ssh -4 <hostname here> > I can confirm that... ~% ssh localhost ssh: Could not resolve hostname localhost: No such file or directory ~% ssh -4 localhost ssh: connect to host localhost port 22: Connection refused
I have read arch linux & redhat bug reports and conclusion seems to be a buggy resolver/nameserver behavior. Although some people confirm that I cannot share their point of view as in my case I do not get NOIMPL answer at all: in all cases I get NOERROR from my resolver. What I noticed is the following pattern when things get broken (eg. www.gentoo.org, www.debian.org): - query: A -> answer: ipv4 address - query: AAAA -> answer: empty (RFC4074) And the folowing pattern when things work fine (eg. www.yahoo.com, www.ripe.net): - query: A -> answer: CNAME + ipv4 address - query: AAAA -> answer: CNAME In such situation resolver is happy and doesn't complain about missing AAAA. To me it looks like the answer to AAAA query "overrides" answer to A query. The only case when it doesn't happen is when answer is a CNAME (in such case things are working fine) or we do not query for AAAA (eg. by disabling ipv6 support in the application).
After some investigation it turned out to be a buggy DNS resolver.. With maradns-1.2.12.09 I get the following results: www.gentoo.org: Name or service not known www.debian.org: Name or service not known www.google.com: OK www.yahoo.com: OK www.ripe.net: OK gnu.org: Name or service not known www.gnu.org: OK while with maradns-1.2.12.10 I get: www.gentoo.org: OK www.debian.org: OK www.google.com: OK www.yahoo.com: OK www.ripe.net: OK gnu.org: OK www.gnu.org: OK I seems like combination of maradns-1.2.12.09 & glibc-2.9 doesn't play nicely..
Created attachment 175555 [details] Sample test C code
I dont know if this has anything to do with this, but: firefox with ipv6 off (network.dns.disableIPv6 in about:config), ipv6 module on: fast lookup firefox with ipv6 on, ipv6 module off (alias net-pf-10 off in /etc/modprobe.d, run update-modules -f): fast lookup firefox with ipv6 on, ipv6 module on: VERY SLOW lookup so it can be a problem with ipv6: http://sourceware.org/ml/libc-alpha/2008-11/msg00008.html where it says "Unified lookup for getaddrinfo." All I know is that removing the ipv6 module speeds ALL lookups on the system. Having the ipv6 module slows down lookups to the point where they time out and fail.
MaraDNS problem description: http://woodlane.webconquest.com/pipermail/list/2008-August/000123.html In my case MaraDNS was resetting RA/RD flags in AAAA answer and this seems to confuse resolver (although with glibc-2.8 it worked just fine).
people who are experiencing this bug should describe the exact dns server (ip address) they are using as well as the software stack running on said server (if they know what it is of course)
(In reply to comment #9) > people who are experiencing this bug should describe the exact dns server > (ip address) they are using Same error pattern here as in comment #4. This happens with the DNS servers of German T-Com, e.g.: 217.237.150.51 f-lb-b01.isp.t-ipnet.de 217.237.150.115 k-lb-a01.isp.t-ipnet.de 217.237.150.188 ul-lb-a01.isp.t-ipnet.de > as well as the software stack running on said server Hm, I don't know how to find this out. fpdns says "Nominum CNS".
added temp change until resolver gets sorted out upstream http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.9/0080_all_glibc-2.10-dns-no-gethostbyname4.patch?rev=1.1
Created attachment 182205 [details] workaround while theres no fix
A fixed maradns package for OpenWRT Kamikaze 8.09 can be found here: http://tikei.de/maradns_1.3.07.09-1_mipsel.ipk
Seems to be the case for glibc-2.10.1 and maradns-1.2.12.9 again (not sure though if glibc-2.10.1 should already include the "real" fix). Just sent request for stabilizing maradns-1.2.12.10 which works fine. Does anyone see this problem with glibc-2.10.1 and other "embedded" resolvers or it's just myself ?
you can always try "options single-request" in resolv.conf to workaround said buggy servers
Doesn't help in my case (maradns-1.2.12.09) - don't know about others: gringo@sun ~ $ epm -q glibc glibc-2.10.1 gringo@sun ~ $ host www.gentoo.org www.gentoo.org has address 209.177.148.229 www.gentoo.org has address 209.177.148.228 gringo@sun ~ $ telnet www.gentoo.org telnet: could not resolve www.gentoo.org/telnet: Temporary failure in name resolution gringo@sun ~ $ grep single-request /etc/resolv.conf options single-request The only way to fix it is to upgrade to 1.2.12.10.
