Re: [DNSOP] DNS privacy : now at least two drafts

Stephane Bortzmeyer <bortzmeyer@nic.fr> Sat, 08 March 2014 17:37 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E371A02B5 for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 09:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6] autolearn=no
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 ewJF3pOYRl33 for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 09:37:40 -0800 (PST)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A11A0205 for <dnsop@ietf.org>; Sat, 8 Mar 2014 09:37:40 -0800 (PST)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 63D2C3C241; Sat, 8 Mar 2014 17:37:33 +0000 (UTC)
Received: by tyrion (Postfix, from userid 1000) id AE17BF00C93; Sat, 8 Mar 2014 18:34:56 +0100 (CET)
Date: Sat, 8 Mar 2014 17:34:56 +0000
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Florian Weimer <fw@deneb.enyo.de>
Message-ID: <20140308173456.GB17348@laperouse.bortzmeyer.org>
References: <20131217112527.GA18176@nic.fr> <87ob1geis0.fsf@mid.deneb.enyo.de> <20140308165741.GA15121@laperouse.bortzmeyer.org> <8761noehzv.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8761noehzv.fsf@mid.deneb.enyo.de>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 13.10 (saucy)
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/jS_aswpioWHbDKWFT-evGYYx57Q
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] DNS privacy : now at least two drafts
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Mar 2014 17:37:42 -0000

On Sat, Mar 08, 2014 at 06:07:48PM +0100,
 Florian Weimer <fw@deneb.enyo.de> wrote 
 a message of 17 lines which said:

> > It is. Section 2.2.2
> 
> Can you quote it here? 

2.2.2.  In the authoritative name servers

   A possible solution would be to minimize the amount of data sent from
   the resolver.  When a resolver receives the query "What is the AAAA
   record for www.example.com?"quot;, it sends to the root (assuming a cold
   resolver, whose cache is empty) the very same question.  Sending
   "What are the NS records for .com?"  would be sufficient (since it
   will be the answer from the root anyway).  To do so would be
   compatible with the current DNS system and therefore could be
   deployable, since it is an unilateral change to the resolvers.

   To do so, the resolver needs to know the zone cut [RFC2181].  There
   is not a zone cut at every label boundary.  If we take the name
   www.foo.bar.example, it is possible that there is a zone cut between
   "foo" and "bar" but not between "bar" and "example".  So, assuming
   the resolver already knows the name servers of .example, when it
   receives the query "What is the AAAA record of www.foo.bar.example"quot;,
   it does not always know if the request should be sent to the name
   servers of bar.example or to those of example.  [RFC2181] suggests an
   algorithm to find the zone cut, so resolvers may try it.

   Note that DNSSEC-validating resolvers already have access to this
   information, since they have to find the zone cut (the DNSKEY record
   set is just below, the DS record set just above).

   It can be noted that minimizing the amount of data sent also
   partially addresses the case of a wire sniffer.

   One should note that the behaviour suggested here (minimizing the
   amount of data sent in qnames) is NOT forbidden by the [RFC1034]
   (section 5.3.3) or [RFC1035] (section 7.2).  Sending the full qname
   to the authoritative name server is a tradition, not a protocol
   requirment.

   Another note is that the answer to the NS query, unlike the referral
   sent when the question is a full qname, is in the Answer section, not
   in the Authoritative section.  It has probably no practical
   consequences.