On Mon, Sep 24, 2007 at 11:18:00AM +0100, Ian Jackson wrote:
COMMON BEHAVIOUR ON TODAY'S INTERNET IS THAT IMPLEMENTED BY
GETHOSTBYNAME.
Common behavior for gethostbyname() on today's Internet is that
implemented commonly in gethostbyname() .
How many times do I have to explain this ?
[In all my comments below, I am assuming that we are focused on rule 9 as
pertains to sorting of IPv4 addresses. A strict sorting of IPv6 addresses
by length of prefix match is also questionable, but not so much so that I
believe overruling is justified.]
On Fri, Sep 21, 2007 at 01:07:49PM
* Clint Adams:
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
glibc is the only implementation I know of that does this.
I have heard, though not confirmed first-hand, that modern
versions of FreeBSD, Windows, and Solaris do as well.
FreeBSD 6.2-RELEASE doesn't do it. And
On Sun, Sep 23, 2007 at 04:21:58AM -0700, Steve Langasek wrote:
On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
So do you have a use case where you think the behavior described in rule 9
*is* desirable?
Any
* Anthony Towns:
I don't agree with making a decision to go against an IETF standard
RFC 3484 is not an IETF standard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
So do you have a use case where you think the behavior described in rule 9
*is* desirable?
Any application written assuming this behaviour, works correctly on
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
As it happens I largely agree with that. I don't agree with making a
decision to go against an IETF standard and glibc upstream lightly,
though, no matter how many caps Ian expends repeating that it's at the
least mature level of
On Wed, Sep 19, 2007 at 05:08:25AM +1000, Anthony Towns wrote:
On Tue, Sep 18, 2007 at 07:18:40PM +0100, Ian Jackson wrote:
There are only three possibilities:
(a) It is correct that the behaviour of applications (and hence of
hosts) should be changed to comply with rule 9.
(b)
On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
So do you have a use case where you think the behavior described in rule 9
*is* desirable?
Any application written assuming this behaviour, works correctly on
Windows, Solaris, *BSD and glibc based systems in general, but not
on
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
glibc is the only implementation I know of that does this.
I have heard, though not confirmed first-hand, that modern
versions of FreeBSD, Windows, and Solaris do as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
I'm not familiar with how getaddrinfo() has been implemented in the
past
I think this is an important point. If you're not familiar with the
history then perhaps I can help explain.
hostname-to-address lookups have up to recently
On Tue, Sep 18, 2007 at 03:33:51PM +0100, Ian Jackson wrote:
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
I'm not familiar with how getaddrinfo() has been implemented in the
past
I think this is an important point. If you're not familiar with the
history then perhaps I can
Anthony Towns wrote:
So if getaddrinfo() has always behaved in this way, I don't see a great
deal of justification in changing it. The bug log indicated that there
were pre-rfc implementations of getaddrinfo() that behaved more like
gethostbyname() at least wrt round-robin DNS; but I've got no
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
So if getaddrinfo() has always behaved in this way, I don't see a great
deal of justification in changing it. The bug log indicated that there
were pre-rfc implementations of getaddrinfo() that behaved more like
gethostbyname() at
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
I've attached a small test program. The results are:
sarge: libc6 2.3.2.ds1-22sarge5: random order
etch: libc6 2.3.6.ds1-13etch2: ordered results
Maybe I should attach it.
Kurt
#include sys/types.h
#include sys/socket.h
#include
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
Heedless of the effect on the DNS round-robin functionality I describe
above, the authors of RFC3484 specified (s6 rule 9) that all addresses
should be sorted by proximity to the host making the choice - where
proximity is
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
So if getaddrinfo() has always behaved in this way, I don't see a great
deal of justification in changing it. [...]
glibc is the only implementation I know of that does
On Tue, Sep 18, 2007 at 07:18:40PM +0100, Ian Jackson wrote:
There are only three possibilities:
(a) It is correct that the behaviour of applications (and hence of
hosts) should be changed to comply with rule 9.
(b) Application behaviour should not change; getaddrinfo should
behave
* Ian Jackson ([EMAIL PROTECTED]) [070918 16:35]:
So RFC3484 s6 rule 9 is just wrong, because the reasons behind it do
not apply any more if they ever did.
I have some stanza from the dns-operations list:
http://lists.oarci.net/pipermail/dns-operations/2007-September/002028.html
| Either it
On Thu, Sep 13, 2007 at 12:14:09AM +, Anthony Towns wrote:
On Thu, Sep 13, 2007 at 12:06:40AM +0100, Ian Jackson wrote:
Does anyone have an answer to my point that application of rule 9
changes the long-established meaning of existing DNS data ?
I'm not familiar with how getaddrinfo()
Anthony Towns writes (Re: glibc's getaddrinfo() sort order):
On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote:
It's atleast in the spirit of the rfc to prefer one that's on the local
network. It might be the intention of rule 9, but then rule 9 isn't
very well written.
Rule 9
On Thu, Sep 13, 2007 at 12:06:40AM +0100, Ian Jackson wrote:
Does anyone have an answer to my point that application of rule 9
changes the long-established meaning of existing DNS data ?
I'm not familiar with how getaddrinfo() has been implemented in the
past -- but I think it makes more sense
I concur with all of Ian's comments, and in particular I would also like to
encourage Kurt to champion this issue to the IETF working group. My own
past experiences suggest that glibc upstream is willing to hide behind
standards not only when they mandate undesirable behavior but also when they
On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote:
It's atleast in the spirit of the rfc to prefer one that's on the local
network. It might be the intention of rule 9, but then rule 9 isn't
very well written.
Rule 9 seems perfectly well written, it just does something you
On ven, sep 07, 2007 at 07:45:52 +, Pierre Habouzit wrote:
On ven, sep 07, 2007 at 07:15:42 +, Pierre Habouzit wrote:
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Also note that probably many many Windows machines work that way (the
RFC was
On Fri, Sep 07, 2007 at 06:54:21PM +1000, Anthony Towns wrote:
OTOH, getaddrinfo is meant to give a close answer, and doing prefix
matching on NATed addresses isn't the Right Thing. For IPv6, that's fine
because it's handled by earlier scoping rules. For NATed IPv4 though the
prefix we should
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
The point is, there is an RFC, and we put a patch so that admins can
disable it using gai.conf.
There is an RFC is not always a good excuse for breaking existing systems.
Admins can disable it is not a
On ven, sep 07, 2007 at 07:15:42 +, Pierre Habouzit wrote:
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Also note that probably many many Windows machines work that way (the
RFC was written by a MS guy). And this behaviour impacts software
Kurt Roeckx writes (Re: glibc's getaddrinfo() sort order):
It's atleast in the spirit of the rfc to prefer one that's on the local
network. It might be the intention of rule 9, but then rule 9 isn't
very well written.
I agree that applying RFC3484 section 6 rule 9 to IPv4 addresses is a
On Thu, Sep 06, 2007 at 10:04:23PM +, Kurt Roeckx wrote:
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
I'm seeking input from the tech-ctte on how to handle this.
Kurt
Pierre Habouzit wrote:
The point is, there is an RFC, and we put a patch so that admins can
disable it using gai.conf.
There is an RFC is not always a good excuse for breaking existing systems.
Admins can disable it is not a good argument when one common class of
the breakage is all the
On Fri, Sep 07, 2007 at 12:34:10AM +0200, Pierre Habouzit wrote:
the Ctte may want to read:
- http://udrepper.livejournal.com/16116.html
- http://people.redhat.com/drepper/linux-rfc3484.html
The first one makes a point to which I party agree, but also disagree.
It's atleast in the
33 matches
Mail list logo
