Hi Shane, On 11/5/24 13:08, Shane Kerr wrote:
I did consider the idea of periodic shuffling. That makes sense to me, since I think we can reasonably assume that servers will not be shuffling at exactly the same time and should have different results. It would mean slightly more state on the server (tracking when the last shuffle was) in exchange for saving the work of re-ordering results on every response.
Instead of every-time or periodic shuffling, you could also keep a best-effort query counter for the RRset in question and rotate the RRset according to counter state. Depending on how it's done, this involves copying two chunks of memory instead of one into the response, with the boundary shifting along. That may be more efficient than invoking randomness. (Of course it may have side effects if consumers not only treat the 1st record specially, but something special with the 2nd, 3rd, ... record as well. I would expect this second-order effect to be negligible, though.) Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
