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

bert hubert <bert.hubert@powerdns.com> Sat, 16 June 2018 05:54 UTC

Return-Path: <bert@hubertnet.nl>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3209D130FB7 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 22:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6mav4DxXj2iR for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 22:54:10 -0700 (PDT)
Received: from xs.powerdns.com (xs.powerdns.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823611277D2 for <dnsop@ietf.org>; Fri, 15 Jun 2018 22:54:09 -0700 (PDT)
Received: from server.ds9a.nl (unknown []) by xs.powerdns.com (Postfix) with ESMTPS id B063E9FB55; Sat, 16 Jun 2018 05:54:07 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 8E252AC407F; Sat, 16 Jun 2018 07:54:07 +0200 (CEST)
Date: Sat, 16 Jun 2018 07:54:07 +0200
From: bert hubert <bert.hubert@powerdns.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Cc: dnsop@ietf.org
Message-ID: <20180616055407.GA16195@server.ds9a.nl>
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com> <20180615171231.GF1126@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180615171231.GF1126@mx4.yitter.info>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GWAMl9VDN3Yb-DLzWnvB8ryQqOY>
Subject: [DNSOP] DoH interaction, sortlist Re: BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2018 05:54:13 -0000

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. 



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

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.