On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA) <kevin.da...@fcagroup.com> 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
