Shane Kerr wrote:
> I wrote a quick draft to specify that answers returned should be returned in
> a random order:
>
> https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
>
> This comes out of recent experience we had where a customer saw significant
> bias in how their servers were used until we randomized the order where
> returned our answers. I confirmed that in many cases neither authority
> servers nor recursive resolvers shuffle the answers; customer reports
> indicate that the actual clients just use the first answer returned.
Hi, Shane:
Anecdotally we have also seen load balancing bias when address record
sets are returned in a fixed order, with very even distributions when
RRsets are rotated (what you call "just rotating" in Section 3.3.1).
While I think it's a good idea for servers to return address RRsets
in such a way that clients don't glom onto one of the addresses and
cause load imbalances, I'm not sure it should rise to the level of a
MUST.
The title is a little inaccurate: "DNS Servers MUST Shuffle Answers".
You have four recommendations in Section 2, but only one of them is a
MUST, and only some of them apply to servers. And the recommendation
that authoritative nameservers perform randomization is only a SHOULD.
I'm also a little bit confused about the use of RFC 2119 normative
language ("SHOULDs" and "MUSTs") in an Informational document. Also,
don't these requirements update STD 13?
Regarding the recommendation for applications ("Applications SHOULD
use RR within an RRset in random order"). How does this interact with
RFC 6724 ("Default Address Selection for Internet Protocol Version 6
(IPv6)") Section 6 ("Destination Address Selection"), which specifies
rules for ordering the list of destination addresses to connect to? It
seems to me that an application that takes a list of addresses produced
by a stub resolver that implements RFC 6724 Section 6 and randomizes
it is effectively ignoring the ordering performed by that algorithm.
Is your recommendation that applications should simply ignore the RFC
6724 algorithm? If so, wouldn't it be better to work on updating RFC
6724?
You refer to applications that use RFC 8305 ("Happy Eyeballs") as
"sophisticated" applications and seem to imply that maybe they don't
need to randomize answers since it's the "naive" applications that
benefit from randomizing:
Whether or not an application stores results is less important than
how the application uses the results. A sophisticated application
may use several of the IP addresses for a given name concurrently,
for example using Happy Eyeballs [RFC8305]. However a naive
application may simply pick the first IP address that it gets back
from the DNS; such applications will benefit from using a resolver
that randomizes answers.
But RFC 8305 (and its successor draft-pauly-v6ops-happy-eyeballs-v3)
require sorting per the RFC 6724 Section 6 algorithm. So it seems like
if there does need to be a normative requirement for applications to
randomize addresses that overrides RFC 6724 it should also apply to
Happy Eyeballs?
There is no Implementation Status section. Looking at a couple of
implementations (BIND and Unbound), I think both of these servers would
violate your MUST ("DNS Recursive Resolvers MUST return RR within an
RRset in random order.") BIND permits configuring per-RRset ordering
policy ("fixed", "random", "cyclic", and "none") but I believe only
one of those options ("random") are compatible with your MUST. Unbound
implements two policies at a global level ("rrset-roundrobin: yes" and
"rrset-roundrobin: no") which I believe control whether rotation is
done, which is what your document calls "just rotating" and also
wouldn't conform to your MUST.
Overall I think it might make sense to have an informational document
that describes the problem, the mechanisms that could be used in the
DNS to address that problem (various kinds of reordering at different
points in the stack, etc.), makes operational recommendations and
encourages implementers to adopt those recommendations as good defaults,
but I don't think it makes sense to try to enforce a new, normative
protocol requirement like this on DNS servers or applications.
--
Robert Edmonds
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
