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

[Shumon Huque <[e-mail]>]

On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA) <[e-mail]>
wrote:

> 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*.
>

This whole thread is about "defaults"  though!

Application deployers attempting to rely (rightly or wrongly) on load
balancing of addresses presented by name resolution APIs will have
preferences for a particular default that allows them to achieve that goal.

(I'm well aware that the spec allows and that OSes provide knobs to tweak
the address selection algorithm - I've lost track of how many times I've
edited my gai.conf file to do various kinds of tests!)

Shumon.