Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-23 Thread Edward Buck
Gabor Gombas wrote: Ok, let's clarify some things here. resolv.conf(5) describes the behaviour of a _single_ resolver query. If you look at resolv/nss_dns/dns-host.c in the glibc source, you'll see that gethostbyname(3) is implemented as _two_ distinct resolver invocations. Since it is nowhere s

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-23 Thread Edward Buck
Stephen Gran wrote: This one time, at band camp, Edward Buck said: If you read further down the man page: "ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made." There'

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-22 Thread Edward Buck
Gabor Gombas wrote: > On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: > >>I find this reasoning very peculiar. If an algorithm is inefficient and >>this causes problems then it is obviously buggy. > > An algorithm is buggy if it does not match the specification. I see no > descripti

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-21 Thread Edward Buck
Marco d'Itri wrote: > On Dec 21, Gabor Gombas <[EMAIL PROTECTED]> wrote: > >>It's not a bug. It may be inefficient, but that's not a bug in itself. > > I find this reasoning very peculiar. If an algorithm is inefficient and > this causes problems then it is obviously buggy. > And it's doubly bugg

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-21 Thread Edward Buck
Marco d'Itri wrote: > On Dec 21, Gabor Gombas <[EMAIL PROTECTED]> wrote: > >>It's not a bug. It may be inefficient, but that's not a bug in itself. > > I find this reasoning very peculiar. If an algorithm is inefficient and > this causes problems then it is obviously buggy. > And it's doubly bugg

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-19 Thread Edward Buck
Stephen Gran wrote: At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-15 Thread Edward Buck
Hi Stephen, Stephen Gran wrote: > This one time, at band camp, Edward Buck said: > >>If you do a 'strace telnet mx1.hotmail.com 25' on a woody machine, >>you'll see that it works according to the documentation. Sarge does >>not. I can forward you more st

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-15 Thread Edward Buck
Hi Gabor, Gabor Gombas wrote: > On Wed, Dec 14, 2005 at 11:41:38AM -0800, Edward Buck wrote: > >>If it's a frequently used feature, it wasn't available until sarge. >>Woody did not behave this way (I checked). > > Huh? > > $ cat /etc/debian_version

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-14 Thread Edward Buck
Hi Gabor, Gabor Gombas wrote: > On Mon, Dec 12, 2005 at 09:13:13PM -0800, Edward Buck wrote: > > >>In a nutshell, when using 'search' lines in /etc/resolv.conf, the >>resolver always appends listed search domains to a hostname lookup even >>when the h

Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf

2005-12-12 Thread Edward Buck
Package: libc6 Version: 2.3.2.ds1-22 Severity: important I originally posted a bug report for postfix detailing the problem but I can reproduce the bug outside of postfix. Here's the postfix bug report in case you're interested: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314891 In a nutsh