Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
Pierre Habouzit writes ("Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch"):
> Cc: ftpmaster@debian.org, debian-release@lists.debian.org,
> debian-ctte@lists.debian.org
>
> Thanks to have kept glibc maintainers in the loop, that was
> considerate.
I had assumed that you'd be following the discussion on debian-ctte.
I'm sorry you hadn't. I'll start CCing glibc@packages.debian.org.
Will that help ?
> On Fri, Sep 28, 2007 at 03:56:31PM +0000, Ian Jackson wrote:
> > I don't know if you've been following the argument on the TC list
> > about bug #438179. I think the Technical Committee are probably going
> > to rule that sid's glibc ought to be changed so that it does not
> > implement RFC3484 section 6 rule 9 prefix-length based sorting for
> > IPv4. This will restore the traditional DNS round robin.
>
> FWIW I still believe that someone in the thread had a point and that
> getaddrinfo should use an extension being e.g. AI_UNSORTED and that the
> issue should be raised to the IETF.
An extension along these lines is no good because the purpose is to
make applications which are updated (usually by upstream) to use IPv6
to continue to behave the same way they used to when they do IPv4.
Saying that we should offer an extension to getaddrinfo to have the
correct behaviour amounts to saying that all callers of getaddrinfo in
Debian should be changed.
> But such a ruling in Debian
> (disregarding Debian's internal power games) has a pretty limited scope,
> and won't fix the fact that most OSes follow Rule 9 and that people that
> use Debian on their servers will still need to use other techniques than
> DNS RR until total world domination is achieved.
Well, it will allow Debian's own ftpmasters to use DNS round robin
because nearly all of the systems which access ftp.*.debian.org are
running Debian.
I'm not sure what you mean by "Debian's internal power games". This
conversation seems to have been entirely about the correct behaviour
of glibc, and how and where to fix it, and pretty much entirely on a
technical level. If you have some conspiracy theory or something
perhaps you'd like to discuss it under a different Subject line ?
> Oh and above anything else I find really intriguing that such a bad
> functionality (at least it seems to be a pretty grave problem given the
> length of some mails on the CT list) has slept in Debian for more than 2
> years unnoticed.
AIUI it was noticed by the ftpmasters when ftp.us.debian.org broke
when large numbers of users upgraded to etch and got the new
behaviour.
> This argument is pure crap and prevent anyone interested to post to
> the TC list. This has pissed me beyond repair on this problem, and I
> believe I wasn't the only one. IMHO, the TC isn't functional with a
> restricted mailing list. debian-release is not under the same
> censorship, and looks though pretty functional to me.
I'm sorry you don't like the way we run our mailing list but that is a
matter for us.
Ian.
Reply to: