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

Mark Andrews <marka@isc.org> Tue, 11 March 2014 08:01 UTC

Return-Path: <marka@isc.org>
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 697941A03DE for <dnsop@ietfa.amsl.com>; Tue, 11 Mar 2014 01:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 luz2ZXDvdBSD for <dnsop@ietfa.amsl.com>; Tue, 11 Mar 2014 01:01:06 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 56BB21A03DB for <dnsop@ietf.org>; Tue, 11 Mar 2014 01:01:06 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 63C0AC94AF; Tue, 11 Mar 2014 08:00:48 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1394524860; bh=yJzBhRforJ/EitQNitWlB2G75DxaBMjAIYlli4BbNFA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=lO6QURdMTeKTg71Ydai7vYPrt41wilfAN/S5Y/K3D7GcyXBaqMvGVoQ6qy2t/9S0p 1yO+MkJ75FRTImvTxyTB7+2lN/FBXFiuiNYS4/jt2GY72ZNX30sO382E9rWFE4Z+VE 0FPbcYL2RMY1BfWuyDzFc9+039d4o4Mb1E0Gou6w=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 11 Mar 2014 08:00:48 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6B33216006E; Tue, 11 Mar 2014 08:01:45 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 06B8516005D; Tue, 11 Mar 2014 08:01:45 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5FCF910E2D41; Tue, 11 Mar 2014 19:00:53 +1100 (EST)
To: Florian Weimer <fw@deneb.enyo.de>
From: Mark Andrews <marka@isc.org>
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> <87fvmsd0nk.fsf@mid.deneb.enyo.de>
In-reply-to: Your message of "Sat, 08 Mar 2014 19:07:43 +0100." <87fvmsd0nk.fsf@mid.deneb.enyo.de>
Date: Tue, 11 Mar 2014 19:00:53 +1100
Message-Id: <20140311080053.5FCF910E2D41@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/cUOVg15UMc-f-M47VIwGABsSQmk
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: Tue, 11 Mar 2014 08:01:08 -0000

In message <87fvmsd0nk.fsf@mid.deneb.enyo.de>de>, Florian Weimer writes:
> * 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.

RFC 2535 said there were no names between NXT owner and the next
name leading to a change in behaviour from RFC 103[45] for empty
non terminals in the range (NXDOMAIN rather than NODATA).

RFC 4034 corrected this to say "the next owner name (in the canonical
ordering of the zone) that contains authoritative data or a delegation
point NS RRset" which handles empty non terminal as NODATA and is
consistent with RFC 103[45].

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

Any resolver that is DNSSEC aware will make NS queries (whether
validating or not).  They do not do so very often as the configurations
that require them to be made are rare.  The majority of recursive
servers in the world are DNSSEC aware.

Nameservers that fail to handle NS queries are broken.  More NS
queries would be good for the overall health of the DNS as it would
flush out the broken servers.

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org