Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
* Mark Kamichoff: Hi - The problem is that the DNS server of your ISP does not conform to the RFC and only answer to the query with a void answer. It never answer to the A query, so the glibc resolver can only conclude the whole query has no answer. Just a thought, many DNS ALGs on firewalls (eg, Juniper NetScreen) will close the UDP/53 session after one packet (response, presumably) is received, and drop any subsequent response packets. This will break other clients, too. For instance, a BIND forwarder without source port randomization, who happens to have multiple queries in flight. Has it been verified that the second DNS packet actually leaves the box? I think there was word of a kernel bug leading to dropped UDP packets which might cause this. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Hi - The problem is that the DNS server of your ISP does not conform to the RFC and only answer to the query with a void answer. It never answer to the A query, so the glibc resolver can only conclude the whole query has no answer. Just a thought, many DNS ALGs on firewalls (eg, Juniper NetScreen) will close the UDP/53 session after one packet (response, presumably) is received, and drop any subsequent response packets. It could be that the DNS servers are fine, just the firewall protecting it is the culprit. I suspect this can be hit or miss due to timing of these events. - Mark -- Mark Kamichoff p...@prolixium.com http://www.prolixium.com/ signature.asc Description: Digital signature
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Mark Kamichoff a écrit : Hi - The problem is that the DNS server of your ISP does not conform to the RFC and only answer to the query with a void answer. It never answer to the A query, so the glibc resolver can only conclude the whole query has no answer. Just a thought, many DNS ALGs on firewalls (eg, Juniper NetScreen) will close the UDP/53 session after one packet (response, presumably) is received, and drop any subsequent response packets. It could be that the DNS servers are fine, just the firewall protecting it is the culprit. I suspect this can be hit or miss due to timing of these events. I don't think this behaviour is allowed by the RFC. Then the problem is in the firewall and not the DNS, but the result is exactly the same for the user. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
On Mon, Mar 16, 2009 at 05:16:13PM +0100, Aurelien Jarno wrote: I don't think this behaviour is allowed by the RFC. Then the problem is in the firewall and not the DNS, but the result is exactly the same for the user. Correct, I'm just moving the finger pointing to the firewall instead of the DNS itself, since the latter may be behaving correctly. I work with these types of firewalls on a regular basis, and might open up a case with our vendor (Juniper), to see if they will fix the behavior. Cisco and others might have the same problem, though, so it could be widespread. - Mark -- Mark Kamichoff p...@prolixium.com http://www.prolixium.com/ signature.asc Description: Digital signature
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Mark Kamichoff a écrit : On Mon, Mar 16, 2009 at 05:16:13PM +0100, Aurelien Jarno wrote: I don't think this behaviour is allowed by the RFC. Then the problem is in the firewall and not the DNS, but the result is exactly the same for the user. Correct, I'm just moving the finger pointing to the firewall instead of the DNS itself, since the latter may be behaving correctly. I work with these types of firewalls on a regular basis, and might open up a case with our vendor (Juniper), to see if they will fix the behavior. Cisco and others might have the same problem, though, so it could be widespread. Upstream has promised to update the current behaviour (which has already been introduced to workaround this kind of problem) and to do the DNS requests using two distincts sockets. We don't know when it will be done though. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Hello,
it seems that DNS resolver is grossly confused, and sends
two DNS requests on same socket back to back (strace below is
from 'lynx http://www.jeep.com'). In first one DNS server
responded only to second packet sent by resolver, and resolve
failed (after that mdns was tried, and eventually lynx reported
error that www.jeep.com does not exist). In second one DNS
server responded only to first packet (in my tests I've never
seen DNS server responding to both requests), and although DNS
resolver still uselessly waited for 5 seconds, slowing web browsing
to being almost unusable, after that 5 seconds DNS resolver
declared success, and moved on.
My /etc/resolv.conf is:
gwy:~# cat /etc/resolv.conf
domain hsd1.ca.comcast.net.
search hsd1.ca.comcast.net.
nameserver 68.87.76.178
nameserver 68.87.78.130
nameserver 68.87.69.146
gwy:~#
It seems to be caused by __libc_res_nquery always sending both
T_A and T_ request when T_UNSPEC query is being sent, and
getting confused when only T_ reply arrives.
2008-05-10 Ulrich Drepper drep...@redhat.com
...
* resolv/res_query.c (__libc_res_nquery): Take two additional
parameters for second answer buffer. Handle
type=T_UNSPEC to mean look up IPv4 and IPv6.
Change all callers.
Sending only one reply seems to be property of Comcast's servers.
When I use DNS server 147.32.1.20 (which runs bind), I'm getting two
responses. I'll try talking to Comcast support, but I doubt they'll
have any idea what I'm talking about.
Petr
16469 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
16469 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
16469 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
16469 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
16469 gettimeofday({1237095720, 803573}, NULL) = 0
16469 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \30\223\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1,
30, MSG_NOSIGNAL) = 30
16469 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \3503\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
16469 gettimeofday({1237095720, 803994}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
16469 ioctl(3, FIONREAD, [159]) = 0
16469 recvfrom(3,
\3503\201\200\0\1\0\2\0\1\0\0\3www\4jeep\3com\0\0\34\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 159
16469 gettimeofday({1237095720, 831053}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4972) = 0 (Timeout)
16469 close(3) = 0
17497 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
17497 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
17497 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
17497 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
17497 gettimeofday({1237096105, 330041}, NULL) = 0
17497 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, 1\311\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1, 30,
MSG_NOSIGNAL) = 30
17497 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, \367\241\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
17497 gettimeofday({1237096105, 330529}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
17497 ioctl(3, FIONREAD, [117]) = 0
17497 recvfrom(3,
1\311\201\200\0\1\0\3\0\0\0\0\3www\4jeep\3com\0\0\1\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 117
17497 gettimeofday({1237096105, 350551}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4979) = 0 (Timeout)
17497 close(3) = 0
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Processing commands for cont...@bugs.debian.org: forcemerge 516218 519774 Bug#516218: getaddrinfo not working while gethostbyname works Bug#519774: libc6: causes many programs not to be able to resolve dns addresses Forcibly Merged 516218 519774. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
forcemerge 516218 519774 thanks On Sun, Mar 15, 2009 at 07:20:42AM +0100, Petr Vandrovec wrote: Hello, it seems that DNS resolver is grossly confused, and sends two DNS requests on same socket back to back (strace below is from 'lynx http://www.jeep.com'). In first one DNS server responded only to second packet sent by resolver, and resolve failed (after that mdns was tried, and eventually lynx reported error that www.jeep.com does not exist). In second one DNS server responded only to first packet (in my tests I've never seen DNS server responding to both requests), and although DNS resolver still uselessly waited for 5 seconds, slowing web browsing to being almost unusable, after that 5 seconds DNS resolver declared success, and moved on. My /etc/resolv.conf is: gwy:~# cat /etc/resolv.conf domain hsd1.ca.comcast.net. search hsd1.ca.comcast.net. nameserver 68.87.76.178 nameserver 68.87.78.130 nameserver 68.87.69.146 gwy:~# It seems to be caused by __libc_res_nquery always sending both T_A and T_ request when T_UNSPEC query is being sent, and getting confused when only T_ reply arrives. The problem is that the DNS server of your ISP does not conform to the RFC and only answer to the query with a void answer. It never answer to the A query, so the glibc resolver can only conclude the whole query has no answer. This is a known problem, upstream has said he is working on a workaround, but you should definitely talk to your ISP first, as the -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Package: libc6 Version: 2.9-4 Severity: grave Justification: renders package unusable This problem is with libc6 2.9-4, althogh my system shows below it's using 2.7-18. I downgraded to avoid the problem. After upgrading to 2.9-4 most programs on my system are no longer able to resolve dns addresses, when connecting to the internet via dhcp with a dsl connection. aptitude update returns this error for every repository: Err http://security.debian.org testing/updates/contrib Translation-en_US Could not resolve 'security.debian.org' Evolution can not send emails, the gnome weather panel applet cannont retrieve information online, etc. Although iceweasel continues to work okay. Upon suggestion from another user, I found that if I configure my system with a specific numerical dns server address, for example from opendns, this serves as a work around. But if the dns server is just the name of my ip (which is the way dhcp configures it) then the problem arises. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.3.3-3 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: pn glibc-doc none (no description available) ii libc6-i6862.7-18 GNU C Library: Shared libraries [i ii locales 2.7-18 GNU C Library: National Language ( -- debconf information: glibc/upgrade: true glibc/restart-failed: glibc/restart-services: -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
