On Nov 5, 2024, at 6:56 AM, Shane Kerr <sh...@time-travellers.org> 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/
(I’ve read the draft and the thread thru Wed 1400UTC, but I am relying to the original post.) I’m surprised no one mentioned “round robin” - a possibly undocumented feature of BIND 8 (showing my age) to rotate the records each time the set was included in a response. With DNSSEC creating a need for a canonical ordering of records within a set (for the purposes of computing and validating answers), this was a bit of a headache. Round robin seemed to assume that all the answers went to the same querier…a bold claim made because of the lack of any documentation…so the rotation might not have ever had the desired effect. But the DNSSEC team was not permitted to remove that feature. A few thoughts: “Random” is probably a bad thing, or at least a “bad word to use” here. In operations, I need predictability first so monitoring and debugging can be possible. Determinism is good. To that end, I’d propose, if you do want to rotate answers, to use, perhaps, the minutes on the wall clock modulo the number of records in the set to indicate which is presented first - the rest then follow in canonical order, wrapping over at the end. This would give predicability…in the sense that a packet trace with time would be able to determine whether the “right” first record was sent. Mentioned in the thread by others: But, there’s still that pesky problem that the records are a set and not an ordered list, so other elements in the pipeline may disrupt any attempt to do traffic shaping/load management in the DNS. And, then there’s that DNSSEC precomputed answer feature. (You could store all permutations…whatever.) I don’t know that the DNS can support application load management all that well. When you look at it through the lens of pure protocol engineering, there are a lot of obstacles. Perhaps pragmatically there can be some benefit, but you have to remember that DNS is not a client-server protocol, the source can’t expect to control the destination. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
