Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

Matthijs Mekking <> Thu, 20 March 2014 07:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B13661A0572 for <>; Thu, 20 Mar 2014 00:42:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.453
X-Spam-Status: No, score=-100.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dXuYWtJ3GELp for <>; Thu, 20 Mar 2014 00:42:39 -0700 (PDT)
Received: from ( [IPv6:2001:7b8:206:1::1]) by (Postfix) with ESMTP id 3FD4E1A03DF for <>; Thu, 20 Mar 2014 00:42:39 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:1db6:e9bb:1364:afe6] ([IPv6:2001:981:19be:1:1db6:e9bb:1364:afe6]) (authenticated bits=0) by (8.14.7/8.14.4) with ESMTP id s2K7gNjN022128 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 20 Mar 2014 08:42:24 +0100 (CET) (envelope-from
Authentication-Results:; dmarc=none
DKIM-Filter: OpenDKIM Filter v2.8.3 s2K7gNjN022128
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1395301347; bh=eldCiawO3FNtXtCdHD30FC6tgZgUBv+0H18yQh4qc28=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=ZE4dKl3FPLBF7A/BkGN5dlDvEjoC0RShXeiY+kIvbo41KMlw3tTKx+4WOQ8i+FBHS uh/Wunh686kZbsoLETYwf1qLcWyZdkMFnKyMZKTs/Nr/OFl5XmWcfYlFIGPlng7R0F SoYxDO/i2EB75x7+Ls0N+cR+3FfGNB4v+nHdgdec=
Message-ID: <>
Date: Thu, 20 Mar 2014 08:42:23 +0100
From: Matthijs Mekking <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>, Ted Hardie <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 ( [IPv6:2001:7b8:206:1::1]); Thu, 20 Mar 2014 08:42:25 +0100 (CET)
Subject: Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Mar 2014 07:42:41 -0000


On 03/19/2014 07:55 PM, Phillip Hallam-Baker wrote:
> On Wed, Mar 19, 2014 at 2:09 PM, Ted Hardie <
> <>> wrote:
>     On Wed, Mar 19, 2014 at 10:40 AM, Phillip Hallam-Baker
>     < <>> wrote:
>         One consequence of encrypting DNS traffic is that we break
>         backwards compatibility. 
>     Howdy,
>     Backwards compatibility with what part of the system?  Or perhaps
>     first, what question are we answering, that makes you presume this?
> Since my client does not currently know about encryption it is going to
> have to be upgraded to send encrypted packets.
> Once my client sends encrypted packets they cannot by definition be read
> unless the receiver has the key and decryption algorithm. Since no
> server currently implements said decryption, a new server is needed.
> Hence the new protocol cannot be backwards compatible with the old.
> There can be a transition path and of course that needs to be
> considered. But both the plug and the socket have to change and so there
> is no reason to insist on the same connector.

My client also didn't knew about DNSSEC and had to be upgraded to
validate responses. We indeed needed a new server that could add those
RRSIG records. But the protocol was backwards compatible. So, I don't
see why we couldn't end up with a solution that is backwards compatible

Best regards,

>     Imagine for a moment that the question is: "How do I prevent
>     exposure of clear text DNS queries from pervasive surveillance when
>     they are sent from my home to a recursive resolver in a data
>     center?"  One answer certainly could be "Set up an IPSEC tunnel
>     between yourself and that data center-based resolver, then run DNS
>     across it".  There are a bunch of trade-offs that will tell you
>     whether that is a good idea, but one piece of the puzzle is that the
>     DNS bits would look exactly the same.
> If the answer was IPSEC then we would be doing it already.
> There are times to persevere and there are times to just let go. IPSEC
> has been in the last category for a decade. 
> Every IPSEC VPN I have ever used has come with instructions on how to
> install a third party IPSEC stack for use with it. And every one of
> those has been an unending tale of incompatibility and instability.
> The only reason to build on existing specifications is to make use of
> existing implementations. If the implementations are huge and unstable
> then its time to move on.
>     There are other approaches which retain the current syntax and
>     change out only the transport (for many other values of transport). 
>     There is no reason to believe those are wrong  on first principles,
>     so let's not start with a "this means DNS 2.0" until we've worked
>     out what the actual issues are, okay?
> My point is that once you decide to change out the transport, you have
> made a major change.
> All I am proposing to do is to change out the transport. I am suggesting
> a KeyExchange + Encapsulation type solution. So it would still be
> RFC1035 messages inside the encapsulation. But we do have some choices
> in the way we design the encapsulation.
> Now you can argue that we could just use IPSEC or DTLS. But those are
> both really complicated protocols and they are both wired up to PKIX.
> Yes, I know that in theory you can do other stuff but in practice you
> can't because the stacks have only been tested for interop on PKIX.
> PKIX is built on top of DNS. Which is not a show stopper form making use
> of PKIX to secure DNS but you have to do it carefully and in a
> controlled way.
> -- 
> Website:
> _______________________________________________
> dns-privacy mailing list