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-boun...@ietf.org> On Behalf Of Florian Weimer
Sent: Monday, June 18, 2018 4:23 AM
To: Erik Nygren <erik+i...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to