Re: Call for Votes (getaddrinfo)
On Thu, Dec 06, 2007 at 07:22:05PM +0100, Kurt Roeckx wrote:
> On Thu, Dec 06, 2007 at 10:22:51PM +1000, Anthony Towns wrote:
> > Well, okay... but shouldn't it still be happening if that's the case?
> > Unless we've somehow lost a significant number of 10.0.0.0/8 hosts that
> > were pointing at ftp/http.us.d.o at that point and now aren't, ike is
> > still the host that they should be all hitting so demonstrating the
> > load imbalance caused by 10.0.0.0 hosts should be trivial if we have
> > any access to ike's logs.
> Afaik, there is a whole bunch of cable users in the 24.0.0.0/8 range in
> the US.
Correct.
Here's a useful reference on both the geographical distribution of IPv4
address allocations, and the density of their assignments (based on
reachability tests):
http://www.isi.edu/ant/address/
One thing worth noting that hasn't been mentioned before now is that all of
224.0.0.0/3 is reserved for multicast, so will never be used as source
addresses for DNS sorting -- that means the maximum possible number of
public client addresses in 192.0.0.0/2 is roughly half that in each of the
other three quarters of the address space. I don't know how this compares
in practice to the inflation of NATed clients in the 192.168.0.0/16 range,
and we probably can't answer that question without significant empirical
study.
Curiously, I have a machine running etch behind a firewall, with a NATed
192.168.x.x address; and when I run a getaddrinfo test for
http.us.debian.org, I get the following (persistent) ordering:
64.50.236.52
64.50.238.52
128.30.2.36
204.152.191.39
35.9.37.225
That looks like a bug in the getaddrinfo() implementation of rule 9 in etch
glibc, above and beyond the concerns over whether it should be implemented?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: