Hi Shane On Tue, Nov 05, 2024 at 11:56:37AM +0000, Shane Kerr wrote: > Dear dnsop, > > 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.
As you are aware, this is an old problem and a config option was added
in DNS implementations for RRset ordering (random, cyclic, etc.).
The problem is in applications that use data such as address RRsets in
the order that they're given to them. It may be best to suggest
strongest action closest to the application layer, e.g., in the
application itself or in stub resolvers ->
getaddrinfo(). Random-ordering (specified as MUST in this draft) in
responses from the resolver can be reordered up the stack and have no
effect. For example, does POSIX require that addresses returned by
getaddrinfo() not be reordered from how they were received by a stub
resolver?
If a customer faces a problem due to ordering, it's easier said than
done to change applications. Perhaps by default stub resolvers can
randomize. E.g., does glibc already randomize by default (and why not if
it is a good idea)? I see no mention of RR ordering in resolv.conf's
manpage. I wonder if there would be any side effects due to that.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
