On Mon, Jun 18, 2018 at 5:14 PM Florian Weimer <f...@deneb.enyo.de> 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
