Just a question on this: was the old/classic behavior really random/shuffled? Or was it that bind would "rotate" through iterations where the order was the same each time if you think of the rrset list as a ring, but with a different start and end point within that ring? (That's what's described here: https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_07.htm)
On Fri, Jun 15, 2018 at 1:17 PM, Erik Nygren <erik+i...@nygren.org> wrote: > On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman <m...@mukund.org> wrote: > >> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote: >> > Round-robin is a documented feature that many applications use. >> Removing >> > it from DNS resolvers, and then having to add it to a much larger >> number of >> > applications, does not seem like a good trade-off. >> >> The _default_ in BIND 9.12 was changed from order random to order >> none. It seems to be missing from the release notes by mistake, but the >> administrator manual mentions what the default is >> > > We have many years of software that relies on emergent behaviors from the > current default. > While pedantically it may be true that these should be treated as > unordered sets and that > applications or stub resolver libraries should do some permutations or > randomized selection, > that doesn't match the current reality for widely used software (eg, curl > and ssh, which I'm > sure is just the tip of the iceberg). > > Software should have safe defaults that matches common expectations. > Those common expectations, as demonstrated by the configuration of all > of the large public resolvers I've tested, as well as by how common > software behaves, > is that the order of results is NOT consistent. In many environments, > this lack > of consistency is relied upon for systems to work properly.. Switching to > consistent > order is no big deal on a small scale, but a widespread shift (eg, as > would happen > due to a change in default in popular software) would almost certainly > have > significant operational impact and is something that warrants significant > discussion > about the practical implications. > > This ambiguity in the current specifications results in this mismatch > between the pedantic (rrsets are explicitly unordered, and a consistent > order is a subset of that) and the current reality (applications and > services > rely on resolvers-at-scale to be explicitly inconsistent in the ordering > of rrsets) > is why I started off by proposing that we may need a BCP or informational > RFC > that describes the currently assumed defaults and best-practices > (ie, round-robin is assumed in many places so don't consistently order > at-scale by default). > > Erik > > > > > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > -- Colm
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
