Round robin results in unbalanced traffic when one or more of the addresses is unreachable. It is not recommended. -- Mark Andrews
> On 7 Nov 2024, at 02:42, Edward Lewis <eppdnsprotoc...@gmail.com> wrote: > > 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 _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
