On ven, sep 07, 2007 at 07:45:52 +0000, Pierre Habouzit wrote:
> On ven, sep 07, 2007 at 07:15:42 +0000, Pierre Habouzit wrote:
> > On Thu, Sep 06, 2007 at 11:46:54PM +0000, 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
> > developpers, and people that hoped that having multiple A records for
> > their service will see a perfect round robin will be stuck anyways. I
> > mean, it's non previous-practice-backward-compliant and one can argue
> > reasonably it sucks. But hel-llooo ! this kind of "design" choice is not
> > only local. If every one (or the majority) on the internet behaves like
> > this, fixing this "bug" (if it is really one) in Debian will _not_, I
> > say _not_ prevent us from fixing many software that rely on DNS round
> > robin, because OTHER PARTIES will use the RFC-foo algorithm, and WE will
> > have to cope with that whatever choice is made.
>
> On that matter, according to Aurélien, Vista (maybe XP),
> {Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
> and solaris come to mind). So it's kind of a decision of Debian vs. the
> rest of the world. And if I don't really care about the issue of the
> decision technically, this aspect worries me.
Still one technical point, here is the excerpt from the RFC on the
offending rule:
Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or
both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if
CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
then prefer DB.
What it means is that for IPs with the same common prefix, the order
of the address is unchanged wrt how it came up in the DNS answer.
What it means, is that when I use apt to fetch from ftp.debian.org
from my home ISP (proxad) it takes the mirror that proxad does
(ftp.fr.d.o). When I go to my parents, using wanadoo (now Orange), it
picks the Oleane one (ftp.fr2.d.o) which indeed is nearer. It makes
completely sense.
And as per rule of the common prefix, on a local network, RR still can
be assumed on a given VLAN. It actually makes quite some sense to me.
Maybe that's why Joey Hess had variability: the RFC does not specify a
*full* ordering, it just aim to restrict the RR to the "nearest"
servers to the client.
Of course, usualy ISP IP's have first octet smaller than 127, so if
you host a service with RR on a network with the first octet greater
than 128 and a mirror on an IP with a first octet smaller than 128, the
client of your service from the ISP will never chose the former because
of this rule. This is a RFC that favors people with large mirroring
networks for their service, and hinders people with small mirroring
networks because they have to chose the IP for their network servers
with care.
I think I've described everything important for the Ctte to rule this,
so unless a question pop up, I'll let you rule in peace :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpDY8OHJ1qKM.pgp
Description: PGP signature