Re: [dns-privacy] DNS + 0-RTT

Shane Kerr <> Mon, 11 April 2016 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D65212E217 for <>; Mon, 11 Apr 2016 05:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xPR103nv0Lvr for <>; Mon, 11 Apr 2016 05:52:54 -0700 (PDT)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D56F12DF71 for <>; Mon, 11 Apr 2016 05:52:54 -0700 (PDT)
Received: from [2001:470:78c8:2:224:9bff:fe13:3a9c] ( by with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1apbKg-0000CR-RD; Mon, 11 Apr 2016 12:52:46 +0000
Date: Mon, 11 Apr 2016 14:52:44 +0200
From: Shane Kerr <>
To: Colm MacCárthaigh <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; boundary="Sig_/0+/PDEY30nyt/vzFh.tkD0L"; protocol="application/pgp-signature"
Archived-At: <>
Cc: "" <>
Subject: Re: [dns-privacy] DNS + 0-RTT
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Apr 2016 12:52:56 -0000


At 2016-04-09 14:58:43 -0700
Colm MacCárthaigh <> wrote:
> > >  This requires only a copy of the target 0RTT section, and access
> > >  to query the resolver, so a typical wifi scenario would do. Multi-RR
> > >  responses are very common these days too.  
> >
> > It strikes me that we should discourage privacy-sensitive resolvers from
> > employing this pattern. though i'm not sure where that documentation
> > would go or how to write it.  Is there a term for this kind of stateful
> > response history leakage?
> >  
> Bind9 calls it "cyclic" rrset-order:
> but I'm not sure if it comes from a recommendation in any RFC - I couldn't
> find one from a quick search.

People who know more can correct me if I'm wrong, but my understanding
is that this sort of RRset rotation is intended to work around clients
that would always pick use first RR from an RRset. Back in the day,
that meant that one gopher server would take all the load. ;)

Obviously a DNS server would prefer not to have to do the work of
ordering queries. If you use cyclic order, then you have to maintain
state about the last answer. If you randomize it, then you need some
source of entropy.

I haven't done a full search, but here's a quick look at support.

On the authoritative side, BIND 9 of course offers any option (fixed
order, round-robin, or ranomized), whereas NSD and I believe Knot are

On the recursive side, BIND 9 again offers any response, whereas
Unbound is fixed (PowerDNS has a feature request for round-robin, but
is currently also fixed (*)).

Like most of DNS, privacy was not considered when developing this

My own recommendation would be that a fixed order be used in all
on-the-wire communication, and that we rely on client-side libraries to
either understand that multiple answers may appear to a question or at
alternatively to randomize the one answer they use. (Note that this is
independent of the privacy concerns, as it results in simpler code and
more deterministic behavior all around.) :)