On Mon 2016-04-11 08:52:44 -0400, Shane Kerr <[email protected]> wrote: > People who know more can correct me if I'm wrong, but my understanding > is that this sort of RRset rotation is intended to work around clients > that would always pick use first RR from an RRset. Back in the day, > that meant that one gopher server would take all the load. ;) > > Obviously a DNS server would prefer not to have to do the work of > ordering queries. If you use cyclic order, then you have to maintain > state about the last answer. If you randomize it, then you need some > source of entropy.
randomized doesn't require a lot of entropy -- it just requires some small chunk at system startup to seed a CSRPNG that you can use indefinitely. > My own recommendation would be that a fixed order be used in all > on-the-wire communication, and that we rely on client-side libraries > to either understand that multiple answers may appear to a question or > at alternatively to randomize the one answer they use. (Note that this > is independent of the privacy concerns, as it results in simpler code > and more deterministic behavior all around.) :) I do like the simplicity and clarity of your proposal, but relying on client-side libraries to be fixed seems like a non-starter, unfortunately. This is the classic IETF problem for any protocol with a deployed base; the folks who have the incentive and capacity to fix some endpoints aren't necessarily the folks who control the "right" endpoints to fix :/ --dkg _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
