Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

Doug Barton <dougb@dougbarton.us> Thu, 20 November 2014 17:19 UTC

Return-Path: <dougb@dougbarton.us>
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 721C31A07BC for <dnsop@ietfa.amsl.com>; Thu, 20 Nov 2014 09:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.697
X-Spam-Level:
X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, 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 ZB6TfEwtji_j for <dnsop@ietfa.amsl.com>; Thu, 20 Nov 2014 09:19:04 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B1B1A1B2A for <dnsop@ietf.org>; Thu, 20 Nov 2014 09:19:04 -0800 (PST)
Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:9526:b013:6890:f301]) by dougbarton.us (Postfix) with ESMTPSA id 4DF1C22B0D for <dnsop@ietf.org>; Thu, 20 Nov 2014 17:19:04 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1416503944; bh=Esi95BjTVNkFT8ekvs2YB4HcLCIh7nk0YiMFDiXB8ps=; h=Date:From:To:Subject:References:In-Reply-To; b=Ti9nJnB3pGLrYZ9KaI5lkdcVmF1pv2TFbhu8vRmkMbMK0ikMMtTp3CoRL39iKw6ru 2YcrxGsjSXtXSVhOVQ5FDabMzhvZhRb7hw0LIjw2YpxFIApslngkgg/RyHMcItmxnl gWiU/tdD1PgiBmoasboyxC/FK4v5nn1WA0tn5M3o=
Message-ID: <546E2287.7080909@dougbarton.us>
Date: Thu, 20 Nov 2014 09:19:03 -0800
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <54691B0A.6060508@gmail.com> <54692F7A.6030803@dougbarton.us> <20141117071250.GA55492@isc.org> <546A73B6.2060005@dougbarton.us> <20141117225045.GA35924@isc.org> <546A873F.8060402@dougbarton.us>
In-Reply-To: <546A873F.8060402@dougbarton.us>
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/gikNuSMqnJ9c7-5J9pPpMRf-QPs
Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
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: Thu, 20 Nov 2014 17:19:07 -0000

The question at the end of this post was a serious one, FWIW.


On 11/17/14 3:39 PM, Doug Barton wrote:
> On 11/17/14 2:50 PM, Evan Hunt wrote:
>> On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
>>> That seems like something that should be fixable in BIND, yes? (And
>>> thanks for doing that testing, btw)
>>
>> Yes, by using two views and slaving the root in one of them and
>> validating
>> in the other one, like it recommends in the draft. :)
>
> :)
>
>> With a single view, if you're authoritative for a zone, then you're
>> the authority, period.  You *know* the corect answer.  Validating
>> yourself
>> to find out whether you're lying to yourself would be somewhat silly.
>
> ... except in the case where you're an authoritative slave, not the
> authoritative master.
>
> But even as the master, let's say you do off-line signing, and now the
> file is sitting on the name server. I would still like to see a knob
> that says "validate everything, even if I'm authoritative for it" since
> that data file may have been tampered with. Perhaps that's needlessly
> paranoid (if they can attack the file they can probably attack other
> things as well), but in the case of a validating resolver that is also
> slaving signed data, "validate everything just in case" makes a lot of
> sense to me.
>
> I would even go so far as to argue that the fact this isn't done is an
> oversight, since even if you're authoritative for a given strata there
> is always a signer a level above you. In the case of the root zone
> that's the root KSK, so even if I'm "authoritative" for the root zone I
> would still want the data in it to be validated when it's used.
>
> ... and yes, I realize that the different views (or different instances)
> trick will work, but now you're doing more work than you would have to
> do if there was a "validate everything" knob, PLUS you have the
> disadvantage of your resolving view caching data for long periods even
> though that data has changed in the slave view. So to me the "validate
> everything" knob seems like a win/win. Am I missing something?