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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Fri, 21 March 2014 14:55 UTC

Return-Path: <bortzmeyer@nic.fr>
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 8A13C1A0989 for <dns-privacy@ietfa.amsl.com>; Fri, 21 Mar 2014 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.547] 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 c1RrqvVpalbH for <dns-privacy@ietfa.amsl.com>; Fri, 21 Mar 2014 07:55:14 -0700 (PDT)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 14EEF1A099B for <dns-privacy@ietf.org>; Fri, 21 Mar 2014 07:55:14 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 342F228015A; Fri, 21 Mar 2014 15:55:04 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 2F73C280102; Fri, 21 Mar 2014 15:55:04 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 2DCA6B3B0BF; Fri, 21 Mar 2014 15:54:34 +0100 (CET)
Date: Fri, 21 Mar 2014 15:54:34 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Phillip Hallam-Baker <hallam@gmail.com>
Message-ID: <20140321145434.GA25219@nic.fr>
References: <CAMm+LwgXExHH6YxpvQLEsgZ+C4uUjvv0E=+g0XBmWVBrQnG_-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+LwgXExHH6YxpvQLEsgZ+C4uUjvv0E=+g0XBmWVBrQnG_-w@mail.gmail.com>
X-Operating-System: Debian GNU/Linux 7.4
X-Kernel: Linux 3.2.0-4-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dns-privacy/ADDzPUcm4GgM2S5cZxbIe_t01MI
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: <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: Fri, 21 Mar 2014 14:55:16 -0000

On Wed, Mar 19, 2014 at 01:40:01PM -0400,
 Phillip Hallam-Baker <hallam@gmail.com> 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 <http://en.wikipedia.org/wiki/Second-system_effect>.

> 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.