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?
>
> 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
Two cases against mandatory ordering:
- glibc's getaddrinfo orders the list received, so any ordering done
*by servers* is going to be undone anyway.
- As an example ordering records is relatevly expensive in the design
PowerDNS Recursor uses: its packet cache has ready-made packets
availble which can be sent out with minimal modifications (think ID
and TTL) that can be done in-place. Ordering records themselves is
much more involved: it would mean moving around variable length
sequences of bytes. We doe re-shuffle on a cache miss when the packet
cache entry is updated.
-Otto
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
