On Fri, Jun 15, 2018 at 01:12:31PM -0400, Andrew Sullivan wrote: > I believe that RRsets are unordered sets by definition. So I supect > that if people are relying on the order in which they come off the > wire, they're making a mistake.
A data point here may be useful. PowerDNS has in many cases not done rrset shuffling on a query by query basis. All our three products employ whole packet caches which send back binary identical responses to equivalent questions, by default for one hour or the lowest TTL entry in the response, whichever is lower. We've been doing this since "forever" and it has indeed led to a single complaint by a cable company with set top boxes that always connect to the first IP address, no matter what. Within PowerDNS Recursor it is possible to override the packet cache on a per subdomain basis, and we know this has been deployed in a very limited number of cases. Setting the TTL to 5 seconds also does it. But otherwise over more than ten years, it appears the reliance on recursors shuffling for each and every answer has not been there for our users (which number in the hundreds of millions of IP addresses served). Based on this, if we write a BCP, I'd be inclined to say that given what is deployed, operators should not count on their resolving nameserver to do the shuffling for them, because there is no guarantee that it will. Crucially, the new DoH spec enables or even encourages HTTP-level caching of DNS messages by existing HTTP infrastructure, which guarantees there will be no shuffling. As an aside, another data point I'd like to mention is an obscure BIND feature we had to clone called 'sort list'. I mention it as obscure since at a recent ISC/CZNIC/NLNetLabs/PowerDNS lunch, no one present of ISC could recall why it was there: the sort list. https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html https://doc.powerdns.com/recursor/lua-config/sortlist.html?highlight=sortlist This is a very powerful feature that makes BIND and the PowerDNS Recursor sort RRSETs in very specific ways, depending on who asks. It turns out that this feature is used in 3GPP environments to route roaming traffic (!). These people very much do not rely on shuffling in the stub, but rely on the first resource record being the one they should use. At that lunch, we could not figure out who originally required such a detailed ordering configuration in BIND, and it might be interesting to find out. But anyhow - as stated above, for non-trivial amounts of resolvers services, shuffling isn't happening that frequently today, so maybe we should not BCP reliance on this shuffling. Bert _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
