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

Florian Weimer <fw@deneb.enyo.de> Sat, 08 March 2014 18:07 UTC

Return-Path: <fw@deneb.enyo.de>
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 3C90D1A024B for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 10:07:51 -0800 (PST)
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_DE=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 taEByAjU3Vbd for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 10:07:48 -0800 (PST)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3E1A02A9 for <dnsop@ietf.org>; Sat, 8 Mar 2014 10:07:48 -0800 (PST)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WMLex-0001iD-Cm; Sat, 08 Mar 2014 19:07:43 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1WMLex-0004i6-86; Sat, 08 Mar 2014 19:07:43 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <20131217112527.GA18176@nic.fr> <87ob1geis0.fsf@mid.deneb.enyo.de> <20140308165741.GA15121@laperouse.bortzmeyer.org> <8761noehzv.fsf@mid.deneb.enyo.de> <20140308173456.GB17348@laperouse.bortzmeyer.org>
Date: Sat, 08 Mar 2014 19:07:43 +0100
In-Reply-To: <20140308173456.GB17348@laperouse.bortzmeyer.org> (Stephane Bortzmeyer's message of "Sat, 8 Mar 2014 17:34:56 +0000")
Message-ID: <87fvmsd0nk.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/0wdm8wh3mxkbWyYcPO-n7fJ5q8Q
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 18:07:51 -0000

* Stephane Bortzmeyer:

> 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

Ahhh, this section heading is wrong, the section is actually
discussing resolver.  The text doesn't explicitly mention
minimization, either. :)

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

There are some odd configurations out there where a query for
www.foo.bar.example/IN/A returns data, but a query for
foo.bar.example/IN/A returns NXDOMAIN.  So it is backwards-compatible
per specification, but a bit thorny to implement in practice.

>    [RFC2181] suggests an
>    algorithm to find the zone cut, so resolvers may try it.

Do you refer to explicit NS queries?

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

But they don't obtain this information in a privacy-enhancing way.

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

Typo.

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

Most resolvers do not make NS queries, and some authoritative servers
do not return useful data (or any data at all).  So using NS queries
for zone cut discovery does not work reliably.