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 ? getad
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?
* 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. An
[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 +1000,
* 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"):
> 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 o
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 o
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 D
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 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 subjec
* 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 [R
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
> behav
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
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
> > "pr
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
#include
#include
#include
#include
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()
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
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 perhap
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 recentl
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 getaddri
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
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.
>
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
fa
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 sh
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
m
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
(reason
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
> >
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
> deve
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
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 spi
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
si
33 matches
Mail list logo