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

Phillip Hallam-Baker <> Wed, 19 March 2014 20:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5305D1A07DB for <>; Wed, 19 Mar 2014 13:02:17 -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 7lO3QAq_1Tv9 for <>; Wed, 19 Mar 2014 13:02:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::230]) by (Postfix) with ESMTP id 15D9D1A07C8 for <>; Wed, 19 Mar 2014 13:02:14 -0700 (PDT)
Received: by with SMTP id gf5so6321637lab.35 for <>; Wed, 19 Mar 2014 13:02:05 -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=8XUztQk315q46lWy+6xgxdmjnb0fkkl71FPkkLGt94A=; b=g6jrtO+OnN2T6VTDS/mras+8R1VMqJCtqSSBiXV/qmFXCnzMyU+bC39yU2jWbSgR2F pLkpYRFk9HCV2fHPbPCwBuMPrqWkm8cQtOi5hMKqf6LtmMhah/1nSIPekkTwPjD+CfIV zJA9jnCf4GwRpZcA0wgbqemKib1rC++OftAAUuGvdFLY1iKLebnEQoynNQEiJfxYHCZD EtYoAsOzLCVR4GOU7ozf5vbU5vrDo/tRTIUQAAbe1jBir7ufh+FjA0laWLXLsTrmKm/2 shRRnFdA6b7hZWYrrjUYCenS8j40S5RcWKkohR6bGe0XaTvVlNbfbXeLTc/S8eadXoTP V8gg==
MIME-Version: 1.0
X-Received: by with SMTP id v9mr2546125lae.44.1395259325733; Wed, 19 Mar 2014 13:02:05 -0700 (PDT)
Received: by with HTTP; Wed, 19 Mar 2014 13:02:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 19 Mar 2014 16:02:05 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Paul Wouters <>
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: Wed, 19 Mar 2014 20:02:17 -0000

On Wed, Mar 19, 2014 at 3:38 PM, Paul Wouters <> wrote:
> On Wed, 19 Mar 2014, Phillip Hallam-Baker wrote:
>> If you take DNS messages and encrypt them, the result is not DNS
>> messages.
> That depends. If you use a new RRTYPE for this, it could very well be
> DNS.
>> If people are encrypting by whatever means, then they should be on a
>> different port. But that is easy enough to do.
> And trivial to block by adversaries?
> Paul

Well, that get us into the whole discussion of what the attack model is.

First off, my DNS privacy proposal is not the OmniBroker proposal I
have been working on for about two years now. What we are talking
about here is just being able to transport DNS protocol between a
client and server with minimal privacy compromise to third parties. In
Omnibroker I support additional queries such as fast access to OCSP
certificate status data and other trusted data.

That said, many of the security considerations are the same. In
particular we have denial of service considerations that are hard and
we want the protocol to have minimal impact on latency.

The problem dealing with blocking of requests is deciding how to
respond. You have basically three options

a) Attempt to tunnel over another protocol
b) Tell the user that they can't go to the site because of blocking
c) Fallback to standard DNS

If the attack is coming from a stupid firewall or other middlebox,
option a is likely to succeed. If the problem is an active attack then
you are going to be left with b or c.

That said, in Omnibroker, the protocol is divided into two parts.

1) Connection (Key Exchange and service discovery) which is always
implemented as a JSON Web Service over TLS.

2) Query/Response which is supported over multiple protocols:

A) UDP Protocol with JSON-B messages
B) Tunneling over DNS TXT requests using BASE-32 & BASE-64
C) As a JSON Web Service over TLS

Option A is available in 97% of network situations and Option B works
in the other 3%. Option C is only necessary in cases where there is an
active attack and the attacker can still block the IP address of the
Web Service if they can work out where that is.

One of the countermeasures I take to prevent this type of attack is
that the client is given the address of the resolver during the key
exchange. This allows me to keep the address of the resolver private.

Keeping the resolver address private does not do anything for me in
IPv4 space. But it provides a lot of leverage in IPv6 world. I can put
every client session on a separate IPv6 address and then filter out
the DoS attacks by IP address.

   [I-D.hallambaker-omnibroker]  Hallam-Baker, P, "OmniBroker Protocol",
              Internet-Draft draft-hallambaker-omnibroker-07, 21 January

   [I-D.hallambaker-wsconnect]  Hallam-Baker, P, "JSON Service Connect
              (JCX) Protocol", Internet-Draft draft-hallambaker-
              wsconnect-05, 21 January 2014.