[In all my comments below, I am assuming that we are focused on rule 9 as
pertains to sorting of IPv4 addresses. A strict sorting of IPv6 addresses
by length of prefix match is also questionable, but not so much so that I
believe overruling is justified.]
On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
> On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
> > So do you have a use case where you think the behavior described in rule 9
> > *is* desirable?
> Any application written assuming this behaviour, works correctly on
> Windows, Solaris, *BSD and glibc based systems in general, but not
> on Debian.
So my argument here is that I don't believe there *are* any applications
being written that assume this behavior; and that even if there were, such
applications would either work just fine with the previous getaddrinfo()
behavior, or be too pathological to live.
The goal of RFC3484 is to describe how system resolvers should sort
addresses in order to give applications the "best" address first. I think
it's already established in this thread (correct me if I'm wrong) that this
specific rule of sorting by the length of the prefix match does *not*
further the goal of sorting addresses from most to least desirable.
Instead, taken over the whole Internet rule 9 is statistically a
pseudo-randomization relative to the *correct* sorting[1], but with features
that make it an outright pessimization for particular real-world hostnames
due to the set of addresses returned. I don't believe any sane application
could depend on such pessimization.
One of the existing use cases that breaks is round-robin DNS. Round-robin
DNS is not an IETF standard; its use has been discouraged by various parties
for years; it has limitations that make it unsuitable for any but the
simplest of configurations. But none of these are reasons to willfully
degrade currently working setups. They might be reasons why RR DNS would be
an acceptable sacrifice in favor of other beneficial features, but rule 9 as
written offers *no* benefits in the general case!
Another possibility is a DNS server that intelligently sorts records based
on knowledge of the client, but returns all the addresses instead of
truncating the list. Arguably it would be more intelligent if the DNS
server didn't return multiple records in this case, but again rule 9 is not
an improvement, so why should it be honored?
> In the bug log, Pierre reported this behaviour is already supported on
> most of those sytems:
> ] On that matter, according to Aurelien, 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.
The purpose of following standards is to foster interoperation between
products of multiple vendors.
Conforming with Section 6, rule 9 of RFC 3484 does *not* improve
interoperation with other vendors. Instead, it breaks interoperation with
existing Internet infrastructure.
Ignoring rule 9 has no foreseeable negative consequences for Debian client
systems. Even if this were an IETF standard and all the rest of the
Internet implemented it, the only consequence of Debian ignoring rule 9
would be that Debian systems would continue to play better than everyone
else with those sites that were in the process of transitioning away from
round-robin DNS.
So I don't see that much weight should be given to whether other operating
system vendors choose to comply with a rule which is, fundamentally,
misguided and broken.
Furthermore, even if gethostbyname() has been deprecated in POSIX, it's
relevant that there is still plenty of software in Debian that uses this
interface[1]. Almost all of this software is going to be IPv4-only; if we
want Debian to be fully IPv6-capable, these are programs that will need to
be updated to use the getaddrinfo() interface, at which point they will
cease to work correctly with round-robin DNS in the absence of additional
code to re-randomize addresses(!). The more work that is needed to make an
IPv4 application function correctly with both IPv4 and IPv6, the less likely
it is that this work will get done; some maintainers may opt not to enable
IPv6 support in their packages rather than use an interface that degrades
behavior under IPv4.
(I wonder how many of the applications in Debian are IPv6-enabled as a
result of local patches, or build options that other vendors aren't
enabling? Debian has touted its IPv6 support since long before other
vendors considered it relevant; perhaps the other vendors that do follow
rule 9 in their getaddrinfo() implementations would take another look too if
their IPv6 support was more pervasive?)
> > Even if you do have one, I still don't see any reason to think this is a
> > reasonable default behavior on the real-world Internet.
> As it happens I largely agree with that. I don't agree with making a
> decision to go against an IETF standard and glibc upstream lightly,
> though, no matter how many caps Ian expends repeating that it's at the
> least mature level of Internet standard. If it's also the case that
> the RFC-specified behaviour is a de facto standard amongst other OSes,
> as the above seems to indicate, then that's even more reason to make
> sure we have a clear decision backed up by good, clear reasoning.
Yes, this isn't a decision to make lightly, but I believe the reasoning I've
offered above is sound.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
[1] where the correct sort order requires detailed knowledge of global
route tables and is therefore not even remotely feasible to implement on any
resolver hosts other than those with a view into BGP
[2] on my etch workstation:
$ for prog in /usr/bin/*; do nm -Du $prog 2>/dev/null \
| grep -q gethostbyname && echo $prog; done | wc -l
257
$
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
