What we should be asking is why a service that needs multiple machines isn’t 
using SRV. It has randomisation between servers explicitly defined along with 
proportional load balancing. 

It also addresses CNAME at the apex which quite frankly is only used to find 
the name of the HTTP server for the zone which SRV  is quite capable of doing.

-- 
Mark Andrews

> On 16 Jun 2018, at 01:45, 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.
> 
> * There are a variety of ways to implement round-robin (randomize, permute, 
> etc).
> 
> * 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).
> 
> 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