Andrew Sullivan wrote:
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
A number of folks have been bitten by a bug in bind 9..12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted).
I believe that RRsets are unordered sets by definition. So I supect
that if people are relying on the order in which they come off the
wire, they're making a mistake.
that's what i've always said. especially after adding round-robin and
getting all the complaints about it. famously one complaint came from
TGV, who had a terminal server product that used TXT RRsets to describe
possible "hosts" that could be reached through their product. for their
internal corporate network, they had encoded carroll's _Jabberwocky_,
one verse per internal server. the bug report that came to me as the
BIND4 maintainer was, "you're scrambling jabberwocky" or words to that
effect. my response when closing the report was, "how can you tell?"
This is a common mistake with unordered data sets; it results in lots
of complaints about SQL data responses, too, for instance. (Of
course, in that case you always have the option of using an ORDER BY
clause, which we don't have in the DNS.)
i think round-robin does more good than harm. another famous bug report
from the BIND4 era when i first added round-robin was from UC Berkeley,
who had two NS RRs for berkeley.edu, and the second one had never
worked, and after i added round-robin, it started to receive queries for
the first time ever. to that complaint i said, "fix your NS RRset."
so while there's no way to please everybody, and while depending on the
order (or in today's case, on the lack of order) of data whose ordering
is not guaranteed is certainly an error, it's very implicit one, and we
need sensible defaults rather than interminable whichness-of-what arguments.
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
