Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

Warren Kumari <warren@kumari.net> Sun, 10 May 2015 10:08 UTC

Return-Path: <warren@kumari.net>
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 227471A0066 for <dnsop@ietfa.amsl.com>; Sun, 10 May 2015 03:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 g6ofQyPvaIno for <dnsop@ietfa.amsl.com>; Sun, 10 May 2015 03:08:03 -0700 (PDT)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1D91A0029 for <dnsop@ietf.org>; Sun, 10 May 2015 03:08:03 -0700 (PDT)
Received: by wgiu9 with SMTP id u9so105101365wgi.3 for <dnsop@ietf.org>; Sun, 10 May 2015 03:08:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+09J+NXlHRpbzAeJffpC4gAUz2JOgFC21qc2A4ljcao=; b=eody44Mo4qN7gnGTUvuQIhmFbKQ2fh62UnmWrwAMInLYOuavcQwy6ZD5nrn1UiaVFj hSFd/5XDZcUom+1nJ80ZMh1iDavaXsSljvmvP1RCmjyuhZN/jZ+NdcZ/7FMk1oaby/S2 PIG+KfazGByGbOEtaLGreCe4BooXEOHObQVpOuc103pKkJtdZf6ugwOf2h1FKHuTmget yBCeLmyOXOu1UjnfHLttVicutrXJTaTFZ8Ck7lUECzr1zjRJzK9Vzzj+c3i8ry11y8DN NLu4XtSVom/2+qnxfdaobDELKho7kUjMprMuNTe8e9+UQtxc1wgvTYGdvn+4QxtKSAze uZIg==
X-Gm-Message-State: ALoCoQnqSU7JjzSxzt6hHwZo/rI/ula642P5q7RokmndWuhYneIKq6vgM+vEljYK4e+5VN+pv88e
MIME-Version: 1.0
X-Received: by 10.180.77.83 with SMTP id q19mr11576144wiw.89.1431252481924; Sun, 10 May 2015 03:08:01 -0700 (PDT)
Received: by 10.194.47.36 with HTTP; Sun, 10 May 2015 03:08:01 -0700 (PDT)
In-Reply-To: <20150509185028.GB74933@isc.org>
References: <553EBF02.3050703@gmail.com> <CAJE_bqc-T75k3sQZKtAF1VHp49biGn+Es5v5FivNSz5e3oB-Cg@mail.gmail.com> <CAHw9_iL9RLp0jynT0m_D6dGZYhmdonvBC-5ifTdB63eh5gvBeg@mail.gmail.com> <CAJE_bqesFPG6d3UsFmtFRjUBQqfifHkaBMR0sXAaNKuN10HL4A@mail.gmail.com> <CAHw9_iLbx_soi1+LaSwMKarLcT1kBCrFdaX8diwMVZp70KeePA@mail.gmail.com> <20150509185028.GB74933@isc.org>
Date: Sun, 10 May 2015 12:08:01 +0200
Message-ID: <CAHw9_iKVtSX5dpVuaMMpM9DQYsTsOd=MqPLgij8vbkQtOpx3Eg@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Evan Hunt <each@isc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/VXa3D0atksA8HqKwlVLWJALpoYk>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors
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: Sun, 10 May 2015 10:08:05 -0000

On Sat, May 9, 2015 at 8:50 PM, Evan Hunt <each@isc.org> wrote:
> On Sat, May 09, 2015 at 03:08:11PM +0200, Warren Kumari wrote:
>> "It is RECOMMENDED that implementations warn operators (or treat as an
>> error) if they attempt to add an NTA for a domain that has a
>> configured positive trust anchor."
>
> You still need to say what happens if the implementation decides to warn
> instead of treat it as an error.
>
> Actually, weirdly enough, after I implemented NTA's in BIND, one of the
> very first applications somebody came up with for them was to temporarily
> disable DNSSEC validation by setting an NTA for ".".  This was seen as
> better than "rndc validation off" because he didn't have to send "rndc
> validation on" afterward; it would just quiety switch itself back on
> after a minute.  It's... actually a pretty clever hack, and I don't
> really want to disable it.
>
> May I suggest:
Yes, yes you may...

> "An NTA placed at a node where there is a configured
> positive trust anchor takes precendence over that trust anchor, effectively
> disabling it.  Implementations MAY issue a warning when this occurs."

and I'll go "Yay! Good text" and copy and paste it into the doc....
and that's what I did....

DONE.

W

>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf