Summary: | sys-libs/glibc-2.9_p20081201 cannot resolve certain names | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcin Deranek <marcin.deranek> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | gfl3162+gbugzilla, loki_val, mattias.fliesberg, ulm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://sourceware.org/bugzilla/show_bug.cgi?id=7060 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 250379 | ||
Attachments: |
Sample test C code
workaround while theres no fix |
Description
Marcin Deranek
2008-12-10 00:34:18 UTC
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. |