Re: glibc's getaddrinfo() sort order
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 defined as the length of the common initial address
> > prefix.
>
> 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 way of
> verifying that.
glibc is the only implementation I know of that does this.
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
On other implementations I'm aware of is in libbind. You'll need to run
configure with the --enable-libbind for that. It doesn't reorder it.
I don't know of any of the other libcs in debian actually provide
getaddrinfo(), but I doubt they'll reorder.
There are also lots of applications that have a wrapper around
gethostbyname() in case the libc doesn't provide it. It's highly
unlikely any of those will do any reordering.
> > This may have been a disputed but arguable definition of real network
> > proximity for IPv6 in at the time 3484 was written. But it is clear
> > now that it is not such a measure in the real IPv6 internet, and it
> > has never been such a measure in the IPv4 internet.
>
> I hadn't seen any indication it was disputed for IPv6 prior to your mail.
> The patch in glibc only affected IPv4 addresses, for that matter.
I've also stated that it might not work properly for IPv6. It's
likely that something in the same /32 is close network wise, it's
even more likely for /48 and /64, but you probably don't want to go
below the /32.
Kurt
Reply to: