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

Phillip Hallam-Baker <hallam@gmail.com> Wed, 19 March 2014 17:40 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 763BA1A0410 for <dns-privacy@ietfa.amsl.com>; Wed, 19 Mar 2014 10:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Zl0_3EGVyHNC for <dns-privacy@ietfa.amsl.com>; Wed, 19 Mar 2014 10:40:12 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B0D411A02F5 for <dns-privacy@ietf.org>; Wed, 19 Mar 2014 10:40:11 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id mc6so6117853lab.41 for <dns-privacy@ietf.org>; Wed, 19 Mar 2014 10:40:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rOzfAnEUGmUtT1f6uY/rZm+0VAZZCqkwAaPWezYaJuQ=; b=rS32MfJcZ/gbKChLUZ86bpwvWeVK9+bhmvoiJfVUpdsK5SIhGNpW2wyhplprZAnu1D GPBUVUd+RQhQbDwGkZqEjwdF+CjX+JHjIuwV1bpbMMnoPeqqd6AbUVyQ1FYF8a2ji1bq QKAJ1JNFXFrj2qH5rL3z6Y1cma1IdsobUYA99PVq8WAwDm1lsH4+dLKbxSOOZ/09rZAJ 74U4LvQScaszbqzl94mKn1TE9TlWT+TNUGZ0HAqiXieZuUOxmwATrSlq+dMIqHZa+Obs NZBk6Bn9N88jktijOVA8TeAeuTb6uYyviUjngRwwmP/SDsPJmSUudlm5wx/l92Phb8zs belQ==
MIME-Version: 1.0
X-Received: by with SMTP id mk6mr26825398lac.13.1395250801306; Wed, 19 Mar 2014 10:40:01 -0700 (PDT)
Received: by with HTTP; Wed, 19 Mar 2014 10:40:01 -0700 (PDT)
Date: Wed, 19 Mar 2014 13:40:01 -0400
Message-ID: <CAMm+LwgXExHH6YxpvQLEsgZ+C4uUjvv0E=+g0XBmWVBrQnG_-w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: dns-privacy@ietf.org
Content-Type: multipart/alternative; boundary="001a113802466274cc04f4f924fd"
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/_oGwA1qdLvCgbfDbNjNuFAu4ybk
Subject: [dns-privacy] Multiple DNS requests per packet, multiple packet responses
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 17:40:14 -0000

One consequence of encrypting DNS traffic is that we break backwards
compatibility. Since we are going to break backwards compatibility we
should take the opportunity to fix some of the problems in the DNS protocol.

In particular, to guarantee compatibility with legacy DNS infrastructure, a
query must:

* Be 500 bytes or less
* Have only one query (QDCOUNT = 1)
* Have a response of 500 bytes or less

Now in practice the first limit it 'usually' not enforced. But going to
encryption is an opportunity to go from 'not enforced' to 'knock it off, if
your implementation does not accept decent sized packets then its broken,
broken, broken'.

I would also like to fix the other two issues. In particular, if we let a
DNS query ask more than one question at a time then we improve latency of
responses. But much more importantly, we also make more interesting
discovery strategies possible because asking for the AAAA, SRV, NAPTR and
URI record along with the A record is no longer a 5 request penalty. And
yes, it really is a penalty because much of the deployed infrastructure
limits the number of parallel DNS queries an app can make in interesting
and painful ways.

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. As in Servers SHALL implement RFC1035 and respond to
queries with QDCOUNT>1. But since I don't think I will get that I will
settle for this being an option that a server can advertise during the key
setup. If the server can tell the client what its key is then it can tell
the client what options it supports.

One problem that comes of multiple requests is the potential for multiple
responses being longer than one packet. And here the traditional thinking
is rather limited.

It is of course highly undesirable for a DNS server to have to respond to
queries that are more than one packet long because that requires the server
to maintain state. And state is expensive. It wrecks anycast, massively
parallel server farms and any number of things that we don't want wrecked.

But returning multiple response packets does not require additional state.
The server just receives a packet, does some work and returns zero to 16
packets in response. Moreover, even though individual queries are slightly
more expensive, the overall load on the server goes down.

One possible objection here is that this would enable more effective
amplification attacks or complicate the DDoS against the server scenario.
These are important considerations and are the main reason I don't want to
try to use IPSEC or DTLS as the basis of a solution. When I started working
on OmniBroker in 2012, these were the issues that drove me to adopt the
architecture I did.

In brief, I don't think we should worry about making DDoS or amplification
attacks worse. Instead we have to have a strategy that allows us to
mitigate them to the point where they are not worth the results.

Website: http://hallambaker.com/