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

Mark Andrews <marka@isc.org> Tue, 18 March 2014 03:59 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 6DFC51A0371 for <dnsop@ietfa.amsl.com>; Mon, 17 Mar 2014 20:59:20 -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 QEzQE7tyo0PG for <dnsop@ietfa.amsl.com>; Mon, 17 Mar 2014 20:59:19 -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 273871A036F for <dnsop@ietf.org>; Mon, 17 Mar 2014 20:59:19 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 02F3EC941E; Tue, 18 Mar 2014 03:58:58 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1395115151; bh=kj+lMibAS3x88zUH2o5KBK60jlgy1ZeMdHjeoDDE/WM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=TUqJmAX6gvTQTCxiBaIHvjSQKbZPfLpgnr5z8l7Koty800wvxeMmURgAVEG8sQB/K H2Ug5ebqmXIZF+FgEqxx2qp023A7rofz5t4ewYPKyfRyBi2oTqnFdZJkXOi3QC+uMB 2gHpHZtXgSm1ymEk4qn9SO4RosFSeR7r5oSMV1Yg=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 18 Mar 2014 03:58:57 +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 238D2160060; Tue, 18 Mar 2014 04:00:02 +0000 (UTC)
Received: from rock.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) by zmx1.isc.org (Postfix) with ESMTPSA id ECEE3160057; Tue, 18 Mar 2014 04:00:01 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 429AF118FFE8; Tue, 18 Mar 2014 14:58:54 +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> <20140311080053.5FCF910E2D41@rock.dv.isc.org> <87y50auqqf.fsf@mid.deneb.enyo.de> <20140317154143.30B51118C508@rock.dv.isc.org> <87a9coiyqc.fsf@mid.deneb.enyo.de>
In-reply-to: Your message of "Mon, 17 Mar 2014 17:19:55 +0100." <87a9coiyqc.fsf@mid.deneb.enyo.de>
Date: Tue, 18 Mar 2014 14:58:54 +1100
Message-Id: <20140318035854.429AF118FFE8@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/UIjusJbkrFuRsbxtEu52zPY8VRw
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, 18 Mar 2014 03:59:20 -0000

In message <87a9coiyqc.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
> * Mark Andrews:
> 
> > In message <87y50auqqf.fsf@mid.deneb.enyo.de>, Florian Weimer writes:
> >> * Mark Andrews:
> >> 
> >> >>>    Another note is that the answer to the NS query, unlike the referra
> l
> >> >>>    sent when the question is a full qname, is in the Answer section, n
> ot
> >> >>>    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).
> >> 
> >> Really?  Where is this mentioned in the protocol RFCs?
> >
> > RFC 3658
> > 2.2.1.2.  Special processing when child and an ancestor share
> >           nameserver
> 
> I think this section is about DS queries, not NS queries.

You need to discover where to send the DS queries.  That means
discovering the immediate parent zone cut.  The usual and suggested
way is to make NS queries with the left most label stripped.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org