tag 343140 + fixed-upstream
close 343140 2.9-1
found 343140 2.9-6
thanks
On Mon, Dec 12, 2005 at 09:13:13PM -0800, Edward Buck wrote:
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
This one time, at band camp, Edward Buck said:
In this case, the algorithm does not match the specification.
Therefore, it's a bug.
Quoting the man page:
Resolver queries having fewer than ndots dots (default is 1) in them
will be attempted using each component of the search path in turn
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's no ambiguity in
On Fri, Dec 23, 2005 at 01:21:54PM -0800, Edward Buck wrote:
The correct query order for mx1.hotmail.com (containing 2 dots) should be:
1. mx1.hotmail.com. -
2. mx1.hotmail.com. - A
3. mx1.hotmail.com.domain1.com. -
4. mx1.hotmail.com.domain1.com. - A
5.
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
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
description about the lookup order wrt.
On Dec 23, Gabor Gombas [EMAIL PROTECTED] 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
Yet another very peculiar definition from you.
On Wed, Dec 21, 2005 at 10:42:03AM -0800, Edward Buck wrote:
On the first point, I (and thus my company) use search lines in
combination with LAN-only DNS subdomains for internal address
management. It allows us to use internal IP addresses for hosts without
fiddling with /etc/hosts. All
On Fri, Dec 23, 2005 at 01:31:16AM +0100, Marco d'Itri wrote:
Yet another very peculiar definition from you.
Well, that's the first thing thaught in programming theory here. If the
algorithm matches the specification, then it is correct. If the
specification does not cover something, then the
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
description about
On Tue, Dec 20, 2005 at 02:47:41PM +0100, Marco d'Itri wrote:
The submitter reported that his system makes three times the usual DNS
queries, and as OS vendors we have a duty to not ship software which
badly interacts with other systems.
It's not a bug. It may be inefficient, but that's not a
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 buggy if its inefficiencies cause are
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 buggy if its
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 buggy if its
On Tue, Dec 20, 2005 at 12:41:05AM +, Stephen Gran wrote:
I guess the answer to this problem for you is to just disable ipv6
(unless you need it) - blacklisting the kernel module(s) ought to do it,
although there may be some other parts I am unaware of.
I doubt disabling IPv6 in the
reopen 343140
retitle 343140 resolver uses the search list before other address families
thanks
On Dec 20, GOTO Masanori [EMAIL PROTECTED] wrote:
Okay, I close it. If you think there's bugs in libc, please tell me
about it.
I think this is definitely a glibc bug, and disabling IPv6 support
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 all domains in the
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 all domains in the
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
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
3.0
$ cat /etc/resolv.conf
search hpcc.sztaki.hu lpds.sztaki.hu sztaki.hu
nameserver
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
3.0
$ cat /etc/resolv.conf
search hpcc.sztaki.hu
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 strace output if it will help. Maybe all
my woody machines are weird. I don't
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 strace output if it will help. Maybe all
my woody
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 host being searched is fully-qualified (contains one or more dots).
No, a host name
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 host being searched is fully-qualified (contains one
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
26 matches
Mail list logo
