Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
Evan Hunt <each@isc.org> Tue, 16 December 2014 17:57 UTC
Return-Path: <each@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 461AC1A700B for <dnsop@ietfa.amsl.com>; Tue, 16 Dec 2014 09:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level:
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 OImZz9eiSjHn for <dnsop@ietfa.amsl.com>; Tue, 16 Dec 2014 09:57:07 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5995F1A854D for <dnsop@ietf.org>; Tue, 16 Dec 2014 09:57:07 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 732991FCADE; Tue, 16 Dec 2014 17:57:04 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 34742216C3D; Tue, 16 Dec 2014 17:57:03 +0000 (UTC)
Date: Tue, 16 Dec 2014 17:57:03 +0000
From: Evan Hunt <each@isc.org>
To: Tony Finch <dot@dotat.at>
Message-ID: <20141216175703.GA68757@isc.org>
References: <20141216011517.21875.32371.idtracker@ietfa.amsl.com> <A086A53B-5187-4498-8BE3-117CFD203DC6@nic.br> <alpine.LSU.2.00.1412161043250.26100@hermes-1.csi.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.00.1412161043250.26100@hermes-1.csi.cam.ac.uk>
User-Agent: Mutt/1.4.2.3i
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/6FLub7LBnv1_Z6PJP_0ZQOGskGU
Cc: dnsop@ietf.org, Rubens Kuhl <rubensk@nic.br>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
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, 16 Dec 2014 17:57:09 -0000
On Tue, Dec 16, 2014 at 10:47:33AM +0000, Tony Finch wrote: > That is a good point. Happily I think the draft already makes it hard for > operators to do that, since an NTA will be automatically removed if its > zone validates (section 10). Thank you for pointing this out, Tony; I'd missed it when I read the draft, and it would have been embarrassing if I'd gone ahead and posted my planned comment to the effect that there ought to be text like this. :) I will revise my planned comments to say there ought to be MORE text like this. First, some clarification of of "attempt to validate the zone" is probably called for. A resolver can't validate the entire zone; it can only spot- check. BIND's method, for the record, is to send a periodic query for type SOA at the NTA node; if it gets a response that it can validate (whether the response was an actual SOA answer or a NOERROR/NODATA with appropriate NSEC/NSEC3 records, which would imply that the NTA was placed at a node which was not a zone cut [1]), the NTA is presumed no longer to be necessary and is removed. (Note that under some circumstances, this is undesirable behavior -- for example, if www.example.com had a bad signature, but example.com/SOA was fine -- so we also provide a "force" option to set an NTA which is *not* subject to this periodic spot-check.) Second, I would upgrade the recommendation from "optimally this is automatic" to at least a SHOULD, and maybe a MUST. Third, it's implied in section 8, but I would add to section 10 that NTAs MUST expire automatically when their configured lifetime ends, and that this lifetime MUST NOT exceed a week. My biggest fear with NTAs is that someone will configure one and then forget about it forever. There should be an expiry date associated with every NTA, and it should be enforced by code. One final comment: in appendix A.2, the "rndc nta" description is outdated and should now read: nta -dump List all negative trust anchors. nta [-lifetime duration] [-force] domain [view] Set a negative trust anchor, disabling DNSSEC validation for the given domain. Using -lifetime specifies the duration of the NTA, up to one week. The default is one hour. Using -force prevents the NTA from expiring before its full lifetime, even if the domain can validate sooner. nta -remove domain [view] Remove a negative trust anchor, re-enabling validation for the given domain. [1] ... which we presume to be legal, but maybe ought to be clarified in the draft. Trust anchors are always at a zone apex; negative trust anchors don't strictly need to be. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
- [DNSOP] I-D Action: draft-ietf-dnsop-negative-tru… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Rubens Kuhl
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Tony Finch
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Warren Kumari
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Evan Hunt
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Rubens Kuhl
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative… Warren Kumari