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 5:14 PM Florian Weimer <[e-mail]> wrote:

> * Paul Vixie:
>
> > in other words we should re-order rrsets by default, so that very few
> > people or agents are ever prone to think their order is stable. the spec
> > says they are unordered, but human nature says, expect more of what
> > you're seeing.
>
> But the client has to sort them again based on shared prefix length
> with its own address.


I assume you're talking about the default destination address selection
rules specified in RFC 6724 (Section 6, Rule 9). Yeah, I agree this doesn't
seem wise to me. I'm not sure what the goal here was - this doesn't get
the client the topologically closest destination (in the general case; even
for IPv6 addresses unless the Internet was using solely provider aggregated
hierarchical routing, which isn't the case).


> I think we should fix that as well, otherwise
> the overall protocol disadvantages new entrants who cannot get a
> contiguous prefix in which they can place all their load balancer
> endoints, so that they are immune from that mandatory client sorting.
>

Client applications delegate address sorting to name resolution functions
like getaddrinfo() - correct?

Doing some quick tests of getaddrinfo() just now on a recent *NIX machine,
it appears to return addresses sorted roughly in accordance with RFC
6724, but rule 9 (longest prefix match) seems to be only applied to
IPv6 addresses. For IPv4 addresses (using an upstream resolver
that randomizes the response RRset), the order returned by getaddrinfo()
is ever changing - I assume presented in the order received.

I haven't actually read the code, so perhaps someone can confirm this, or
share what portions of the default address selection algorithm common
name resolution libraries actually implement.

Shumon.