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

Phillip Hallam-Baker <> Fri, 21 March 2014 15:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53AA41A09E8 for <>; Fri, 21 Mar 2014 08:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BNHS2J-efixK for <>; Fri, 21 Mar 2014 08:55:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::229]) by (Postfix) with ESMTP id EBA451A06D2 for <>; Fri, 21 Mar 2014 08:55:48 -0700 (PDT)
Received: by with SMTP id q8so1798473lbi.14 for <>; Fri, 21 Mar 2014 08:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tJpbPkFpfw9hb3Qg79jz7zGZmBsPVJb46SxqTEwcmmw=; b=oqszE37hyjfbHM5sFrCnqviWlPa3RSHk7Q5p3JGCe7NZ18Ry0LYWw6i0fphwrnaGWY wsDGz6PvP/5ziemsPPAGoExLDL+KWFiKTfWDh+3dk1jywyNIfVYvFqPrWtsnJNcJbCIB OpEVrqCa+25W9ggMr3Rd67DCHvHIm7xz4ja+8RDPdrdW8B3Wv4FrE8O5bS7LAeqyfPtd eHOdHc/In1Gkwq/G4DfB2P2ViWsMfbYpDVvVKxH+PBq9UsxVzhZc5fRRl3zOffMVA6Fq Jhpc3/y40GjVk0EeNxDgIExQbtvZQzZMIFg8wN9wJ5uajHWOkelJXCh0tbCqQR318cHx M2rg==
MIME-Version: 1.0
X-Received: by with SMTP id jj8mr63323lac.70.1395417338805; Fri, 21 Mar 2014 08:55:38 -0700 (PDT)
Received: by with HTTP; Fri, 21 Mar 2014 08:55:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 21 Mar 2014 11:55:38 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Stephane Bortzmeyer <>
Content-Type: text/plain; charset="ISO-8859-1"
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: Fri, 21 Mar 2014 15:55:53 -0000

On Fri, Mar 21, 2014 at 10:54 AM, Stephane Bortzmeyer <> wrote:
> On Wed, Mar 19, 2014 at 01:40:01PM -0400,
>  Phillip Hallam-Baker <> wrote
>  a message of 144 lines which said:
>> One consequence of encrypting DNS traffic is that we break backwards
>> compatibility.
> Just a reminder: "This list is for the discussion of the problem
> statement surrounding the addition of privacy to the DNS protocol."
> Privacy is the goal, encryption may be a solution. This list is
> dns-privacy, not dns-encryption.
>> Since we are going to break backwards compatibility we should take
>> the opportunity to fix some of the problems in the DNS protocol.
> I disagree with this approach: adding encryption, should we decide it,
> is more than enough work to keep an IETF mailing list active for many
> months (years?) Saying "hey, cool, the gates are open, let's try to
> push all the other stuff I want" seems a sure recipe for a second
> system failure <>.

And end up with systems like DNSSEC which have taken as long as they
have because necessary changes to the protocol were fought tooth and
nail for absolutely no good reason.

There is no point in a specification that nobody is going to use
because they can't or it does not solve enough problems. Right now we
have a million people trying to connect to Twitter despite DNS
blocking. That is just as important a use case as stopping other
governments seeing that people are connecting to Twitter.

If people were willing to think about new ideas for just 5% of the
time they spend trying to block them in the DNS space because they
find the idea of new ideas scary we might get somewhere.

DNSSEC would have been deployed in 2002 if you had been willing to
consider doing things my way. You guys never intended to give me a
chance to help you then.

The main reason everything takes so long in the DNS area is that there
are so many people that think they add value by creating friction and
opposing every proposal before they have even heard what it is.

I have been thinking about and publishing on this problem for over two
years. As a result I know the problem space, the solution space and
the cost of various options pretty well.

>> So I would like to require a server that supports the crypto query protocol
>> to be required to actually implement what is written in 1035 and respond to
>> multiple queries.
> RFC 1035 is quite broken here since it does not say how to set the
> status code when the different questions yield differente results. In
> the last years, several people have proposed to update RFC 1035 to
> make this scheme workable (for instance by requesting that all the
> questions use the same qname or by having several response packets, as
> you suggest) but it never went far.

I did wonder about that. But I think I have a solution as follows.

PRIVATE-DNS (my scheme) has

1) a key exchange used to setup a relationship between a client and
server. That just reuses TLS at the moment but I expect that some
extra crypto will end up in the mix.

2) a wrapper for transporting DNS messages.

A simple wrapper would be something like:


ContextID:    Byte []   // The cryptographic session information
TID:    Byte []   // Transaction Identifier and Initialization Vector
for the crypto
Data: Byte []   // The encrypted DNS Request message as per RFC1035
MAC:   Byte []   // Authentication code (possibly optional)


TID:    Byte []   // Transaction Identifier and Initialization Vector
for the crypto
Data: Byte []   // The encrypted DNS Request message as per RFC1035
MAC:   Byte []   // Authentication code (possibly optional)

Since the IV is 128+ bits of random data it makes perfect sense to
reuse it as a transaction identifier for matching requests and
responses. To do this securely the mechanism for converting the TID to
the IV has to be different on requests and responses. The simplest
scheme would be to XOR the TID and MAC values from the request to
produce the IV for the response.

All that is needed to put multiple requests in a request packet is to
change the schema to be:


Data: Byte []   // Encrypted list of DNS Request message as per RFC1035

i.e instead of the encoding being something like

<length> <bytes> <data-padding>

It would be

<length> <bytes> (<length> <bytes>) * <00> <data-padding>

For an application like DNS, the length of the message can reveal a
great deal about the request. So adding padding to bulk up the message
to an
integral multiple of 64 bytes (say) is quite important.

The data framing for the response would be the same except that if we
wanted to support multiple response packets the format of each packet
would be something like:


PacketIndex:  Integer (0..15)
MaxIndex:  Integer (0..15)
TID:    Byte []
Segment:   Byte []

To process responses the client must first receive all the response
packets, match them to the request and assemble them in order. The
inner encoded data is then

<length> <bytes> (<length> <bytes>) * <00> <mac> <data-padding>

The responses are given in the same order as the original requests.

This mechanism is limited to 16 response packets (requests are always
1 packet). This is probably close to the upper limit for reliable UDP
since the receiver has to receive all the packets to use them. But
this is almost certainly ample for virtually all DNS queries we might
want to make.

Allowing multiple requests/responses does make the client
implementation a little more complex. But it avoids the need to
fallback to TCP which these days only works reliably on ports 80 and
443. It reduces latency and network traffic.

The big advantage is that it means that we can use DNSSEC now without
having to constantly worry a little bit of extra data in the response
is going to cripple performance and reliability due to clients having
to fallback to TCP over port 53.