> On Jun 15, 2018, at 11:45 AM, Erik Nygren <erik+i...@nygren.org> wrote:
> 
> A number of folks have been bitten by a bug in bind 9..12 where it silently 
> changes the default sorting of rrsets to always be sorted (even if the 
> authoritative response wasn't sorted).  This causes problems for services 
> assuming at least some degree of round-robin behavior by clients as now many 
> clients would sent all traffic to only the lowest IP.  Bug details:  
> https://gitlab.isc.org/isc-projects/bind9/issues/336   If you are upgrading 
> to or have upgraded to bind 9.12 you likely want to take a fix or override in 
> config.
> 
> 
> This raises the question of whether there would be value in a more modern BCP 
> covering round-robin expectations for recursive resolvers?  I suspect many 
> (most?) service operators take at least some degree of DNS round-robin 
> behavior by recursive resolvers as a default.
> 
> I suspect starting assumptions are roughly in the range of:
> 
> * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin 
> in RRset responses.

Stub is in your desktop (and possible application, but may vary depending on 
OS, etc).

> * There are a variety of ways to implement round-robin (randomize, permute, 
> etc).

Sure, but services should also be sufficiently robust should there be some 
amount of polarization in the hash algorithm.  I recall when the entropy went 
into bind4 to assist with balancing of some web services as well as mail/ftp 
stuff.

Perhaps this is something that could be done better with a flavor of 
happy-eyeballs in the client application, whereby you race not just v4 vs v6 
but also some limited subset of answers the application gets back as part of 
getaddrinfo()

> * Server operators need to be aware that round-robin may be a part of a load 
> balancing scheme (especially if capacity is far greater than average demand) 
> but should not be relied on exclusively.  (Perhaps with examples of why...)
> 
> Am I missing something in-terms of an existing BCP to this effect?  There's 
> RFC 1794, but I couldn't find much else (but given the sheer number of DNS 
> RFCs it's very likely I missed one).

Have you checked the DNS Camel :-)

https://powerdns.org/dns-camel/

I didn’t find anything else looking real quick, and it gave me a reminder of 
some of the folks that I used to interact with at ANS back in the day, so at 
least for a Friday it’s a fun and quick re-read to hit up 1794.

- Jared

> 
> Best, Erik
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to