On Wed, Sep 19, 2007 at 04:52:35AM +1000, Anthony Towns wrote:
> Ah, that'll be because the ordering's simply rotating, rather than being
> random: so we're assuming from A > B,C,D > E and getting:
> ABCDE -> ABCDE
> BCDEA -> ABCDE
> CDEAB -> ACDBE
> DEABC -> ADBCE
> E
* 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 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 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
* Anthony Towns ([EMAIL PROTECTED]) [070918 20:53]:
> On Tue, Sep 18, 2007 at 05:09:43PM +0100, Ian Jackson wrote:
> > Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> > > [stuff]
> > 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
> >by Debian systems, but we do no
On Tue, Sep 18, 2007 at 05:09:43PM +0100, Ian Jackson wrote:
> Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> > [stuff]
> So, trying to keep stuff simple, I propose:
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
>by Debian systems, and we overrule the maintain
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
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
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
Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> [stuff]
So, trying to keep stuff simple, I propose:
1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
by Debian systems, and we overrule the maintainer.
2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
b
Julien Danjou writes ("libconfig name clash"):
> My arguments are the following: abz's libconfig is old, non used
> (no reverse-dependencies) and has only 40 installs according to popcon[2].
> Furthermore, it's packaged as a native Debian package and does not seems
> to be distributed anywhere. I d
* Ian Jackson ([EMAIL PROTECTED]) [070918 16:35]:
> I think this is an important point. If you're not familiar with the
> history then perhaps I can help explain.
> As I have demonstrated above, the RFC is wrong, inconsistent with
> existing practice, and the proposed way of complying with it cau
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
15 matches
Mail list logo
