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

Doug Barton <dougb@dougbarton.us> Sun, 16 November 2014 23:13 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 690431A1BFA for <dnsop@ietfa.amsl.com>; Sun, 16 Nov 2014 15:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 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.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 wrnl4RKS1Sr3 for <dnsop@ietfa.amsl.com>; Sun, 16 Nov 2014 15:13:00 -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 916A11A1BFC for <dnsop@ietf.org>; Sun, 16 Nov 2014 15:13:00 -0800 (PST)
Received: from bcn-dbarton.lan (unknown [IPv6:2001:470:d:92:2054:a23a:ad2:ab8]) by dougbarton.us (Postfix) with ESMTPSA id 0D09422B0D for <dnsop@ietf.org>; Sun, 16 Nov 2014 23:12:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1416179579; bh=nCaKaRxxnlswy2/pPAW5sEWGwR9T9KW+ML5tRAjrCKc=; h=Date:From:To:Subject:References:In-Reply-To; b=TByQwXD4ttLZ5xfcroDDY0kO0GJBr7A8SIz87ycfhMKiO5/DPH1QCxdbaufRWj3xJ BYprencOCk0EQutui+E1LucMNvpng8cD4w7f/p8heqHDRTPSIt3iqJmJPSStGp8PI1 IJH/SdPVHQyXrFACZZRLdnu9dvV33TORkR+q+AF8=
Message-ID: <54692F7A.6030803@dougbarton.us>
Date: Sun, 16 Nov 2014 15:12:58 -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>
In-Reply-To: <54691B0A.6060508@gmail.com>
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/UiDgTHK-l62ifM90Ir1MkRlyzGA
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: Sun, 16 Nov 2014 23:13:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/16/14 1:45 PM, Tim Wicinski wrote:
|
| This starts a Call for Adoption for
| draft-wkumari-dnsop-root-loopback

I have read the draft, I support its adoption, and I will review and
contribute text as necessary.

It should come as no surprise that I'm in support, as I've been
advocating slaving the root zone locally since 2001. :)

The one flaw I see in the draft is that the configuration it
recommends is needlessly complex. Where possible (such as for BIND)
slaving the zone in the resolver instance gives a lot of benefits, and
few drawbacks. Before commenting further I'd love the authors to flesh
out their reasoning for not simply slaving the zone where possible.
There is currently some mumbling about the resolver not handing out
AA, but no reasoning as to why that is a problem. I've read the
threads on the original draft, and on this one, and there was some
good discussion of pros and cons there, I'd like to see some of that
discussion in the text. (And yes, I'm aware that one of the primary
motivators is DNSSEC, but the only thing in the root that we care
about are the DS records, and a validating resolver is going to chase
those up to its trust anchor anyway.)

Doug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUaS96AAoJEFzGhvEaGryEOf8IALMQEt2gg3SUuJs8VKSz5w40
lcrooyF+NUrqS3+uWdlzIddHsm2fqluXV25QNiRDySn7J/We/dsokBr8RxH7nqLc
aSupz/domI7uTaPD/hz7LR/5HNf/7vCfUrlhlWn9FoboZQy7FeOqFr8HQrGSEKw1
IsXCCHK23U9QEQM16I96kBCUO+JSM+w1ACqKaSo3qJMxG37fAAzPSga0X6UeLlaJ
+amLZzWu5I2QrbhqQNYeFm4t5jDg2wi8NrS8u5IxDSWRUEWrNnz9lO4UpjOl8gjo
EQS+T618nUeLBawFxMNmcrFMU4SS6654oD0ttXGN+hbxoXBAVRJMHCuGMlXMcik=
=hAqD
-----END PGP SIGNATURE-----