Return-Path: X-Original-To: dns-privacy@ietfa.amsl.com Delivered-To: dns-privacy@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EF41A0418 for ; Wed, 19 Mar 2014 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXomENhgN1Ko for ; Wed, 19 Mar 2014 11:10:18 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E011E1A0410 for ; Wed, 19 Mar 2014 11:10:17 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so9272766iec.37 for ; Wed, 19 Mar 2014 11:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nowDLalyxcz2T2bKuaG5z0l3ZOf56LZU4pGTrNK4oLw=; b=Dj7QfOkOKp/jf4lA2pLYUQyIy37n3MMsKGcDuHG+YlR2fIW3elPOkimQjdZHpHa+WU /BfCGk39yDOS6VMyLplv2maMPiFWc8ho/xIe33jbpmdOXRUtucYGaSAAg4SD/Rai54vv IId9Foeerhiou4yr0hhYCDa35yr2jDe5WGmx3B2GkMDx/0CBo7LDtOIjsH2Td0PpCXnR 73ECMwu1epoH/QEePTIrHk8orK8EzFD8OnG3AzAWOWGbV2S0uZl2v8HlLo6/5H2StLwa RyjW7UthyR13hhGpu8pcLO6WO5wgdwwH0wXyIz92sA2yvr/JgGP8ryb+eg1k+UoxKEru 3caA== MIME-Version: 1.0 X-Received: by 10.50.57.17 with SMTP id e17mr27131302igq.13.1395252557582; Wed, 19 Mar 2014 11:09:17 -0700 (PDT) Received: by 10.42.237.206 with HTTP; Wed, 19 Mar 2014 11:09:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Mar 2014 11:09:17 -0700 Message-ID: From: Ted Hardie To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=e89a8f2354fd1138f204f4f98d20 Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/bhrnUT3RVcH2IumPWrgUq2tkTFU Cc: dns-privacy@ietf.org Subject: Re: [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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 18:10:21 -0000 --e89a8f2354fd1138f204f4f98d20 Content-Type: text/plain; charset=ISO-8859-1 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? 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. 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? regards, Ted Hardie > 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/ > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > > --e89a8f2354fd1138f204f4f98d20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 19, 2014 at 10:40 A= M, Phillip Hallam-Baker <hallam@gmail.com> wrote:
One consequence of encrypti= ng DNS traffic is that we break backwards compatibility.

Howdy,=

Backwards compatibility with what part of the system?=A0 Or perhaps fir= st, what question are we answering, that makes you presume this?

= 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 fr= om my home to a recursive resolver in a data center?"=A0 One answer ce= rtainly could be "Set up an IPSEC tunnel between yourself and that dat= a center-based resolver, then run DNS across it".=A0 There are a bunch= of trade-offs that will tell you whether that is a good idea, but one piec= e of the puzzle is that the DNS bits would look exactly the same.

= There are other approaches which retain the current syntax and change out o= nly the transport (for many other values of transport).=A0 There is no reas= on to believe those are wrong=A0 on first principles, so let's not star= t with a "this means DNS 2.0" until we've worked out what the= actual issues are, okay?

regards,

Ted Hardie
=A0
Since we are going to break backwards compatibility w= e should take the opportunity to fix some of the problems in the DNS protoc= ol.

In particular, to guarantee compatibility with legacy DNS in= frastructure, a query must:

* Be 500 bytes or less=
* Have only one query (QDCO= UNT =3D 1)
* Have a response of 500 bytes or less

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

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

So I would like to require a server that supports the c= rypto query protocol to be required to actually implement what is written i= n 1035 and respond to multiple queries. As in Servers SHALL implement RFC10= 35 and respond to queries with=A0QDCOU= NT>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 s= erver can tell the client what its key is then it can tell the client what = options it supports.


One problem that comes of multip= le requests is the potential for multiple responses being longer than one p= acket. And here the traditional thinking is rather limited.

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

But returning multiple response packets does not requir= e additional state. The server just receives a packet, does some work and r= eturns zero to 16 packets in response. Moreover, even though individual que= ries 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 a= gainst 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 issu= es that drove me to adopt the architecture I did.

In brief, I don't think we should worry about makin= g DDoS or amplification attacks worse. Instead we have to have a strategy t= hat allows us to mitigate them to the point where they are not worth the re= sults.

--
Website: http://hallambaker.com/

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy


--e89a8f2354fd1138f204f4f98d20--