Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the implementation has other
means of sorting destination addresses. For example, if the
implementation somehow knows which destination addresses will result
in the 'best' communications performance."

So, technically, if an implementation chooses a method of "the exact order in which I received the address records from my upstream resolver" as a way to produce the "'best' communication performance", given the circumstances, then that is technically not a violation of the standard. The local optimization is to trust the upstream resolver to Do The Right Thing. It's not always a wise choice, but most of the time it's better than sorting based on prefix-length matching (right?)

RFC 6724 is, after all, about *default* address selection (that word is even in the title of the RFC). Defaults are made to be superseded -- that's kind of the definition of what a default *is*.

											- Kevin

-----Original Message-----
From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Florian Weimer
Sent: Monday, June 18, 2018 4:23 AM
To: Erik Nygren <erik+ietf@nygren.org>; dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

On 06/15/2018 05:45 PM, Erik Nygren wrote:
> 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?

Unless all addresses happen to have identical shared prefix length with the client address (that is, count-leading-zeros(client-address XOR
server-address) is the same), RFC 6724 Rule 9 requires that clients do
*not* perform random server selection.

I think this was a mistake in RFC 3484, and it is still wrong.  But I think procedurally, you cannot change this in a BCP.

Thanks,
Florian

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