On Tue, Nov 05, 2024 at 09:15:15PM +0800, Mukund Sivaraman wrote:
> 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?
And when there's some other software meddling in the middle, eg:
VPN, systemd (ick), nscd
> 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.
This sounds like a change towards the stub or in the OS/stub
would be best. I expect some resolvers might even prebuild their
responses so they can go out faster, so then you have to maintain more
state to shuffle at each layer.
btw: in general I think this does deserve a doc and adoption but
worry it will end up with rfc6919 section 2 or 4 language.
- jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
