Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

Joe Abley <jabley@hopcount.ca> Sat, 07 December 2013 21:52 UTC

Return-Path: <jabley@hopcount.ca>
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 D7B9F1AE432 for <dnsop@ietfa.amsl.com>; Sat, 7 Dec 2013 13:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pBrdMwjhOGoc for <dnsop@ietfa.amsl.com>; Sat, 7 Dec 2013 13:52:19 -0800 (PST)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E2D3D1AE430 for <dnsop@ietf.org>; Sat, 7 Dec 2013 13:52:18 -0800 (PST)
Received: by mail-ig0-f171.google.com with SMTP id c10so403131igq.4 for <dnsop@ietf.org>; Sat, 07 Dec 2013 13:52:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=899m+eROCUGFcVzJ6f3F7uMfqR4KJ8y1Cs7GxZJGt9M=; b=hxTAsH/yUh9+7R9ytEPa9wxoL3TtOnyVrE9ci5S7OFgBTOYzxFHE+edSOETSh1A5zN LM2eB0r3H4uCfxNc3CqnSMDv8ZrD4DLCKXrmvd0Bx+UqqsQpzqlwYi1V2rdFej608n7M nwnMGF4VdoMVlxaS+WopAi2ZS/TspSKSoR29k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=899m+eROCUGFcVzJ6f3F7uMfqR4KJ8y1Cs7GxZJGt9M=; b=Dxwb2wRs1nRDUvm74eS+Wdo2UHCEmw2EFiUqG9JvTZkgd4Bhq3Zb4i1YwB/pNZuf/Z vDoX0ZZqx/q3Z6sGamm1EvaG5Q6Mc64wOqyGq/f0LF8ly+VkMOsn27q3EYQsd4VmdGNm xq50qLBU1B3WY/m8I9S0PiXldYUw2U26xZ58KN0HTdOUzAiCfsX7Js6i/4DCXxnZVnBE 8YY4MbU/JhTLAU0FnxuaWVcCUOJ/xYNYqqvXBuu1phkOb89DN/R7+uwtuG+94q2WmKhH fYq5GIud523g8tW6QzC/4+tD7Z90nIUItjJBFH67PcE20I2WRrgpDlLJWa4CjJBIksa0 TYtQ==
X-Gm-Message-State: ALoCoQmx8CO37S3IMv6Vp/6bohzv0+7zEYp0v6/vrNEwmh5WHh9q3O55BOYkkPo4cq0MiT/fEuGT
X-Received: by 10.42.204.4 with SMTP id fk4mr64794282icb.31.1386453134602; Sat, 07 Dec 2013 13:52:14 -0800 (PST)
Received: from [199.212.90.48] (24-52-234-221.cable.teksavvy.com. [24.52.234.221]) by mx.google.com with ESMTPSA id v2sm5384374igz.3.2013.12.07.13.52.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 13:52:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_18BA31E7-FF11-4A50-B56E-32087C675C39"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <Prayer.1.3.5.1312051215460.21609@hermes-2.csi.cam.ac.uk>
Date: Sat, 7 Dec 2013 16:52:10 -0500
Message-Id: <0AE0E07B-2509-440D-81CF-4A75A7F95F45@hopcount.ca>
References: <BF87877A-8989-4AA4-9ED1-52C82E1BC538@nominum.com> <alpine.LFD.2.10.1312011206480.12923@bofh.nohats.ca> <20131202151651.GD16808@mx1.yitter.info> <A12FD3E0-58F6-4490-877F-A9C59405F717@vpnc.org> <6DBBC8339C394DBDAE4FE1F764E02A8D@hopcount.ca> <20131203170825.GA17211@nic.fr> <21D03162-81D1-494A-89A9-41BE89D28A0E@nominum.com> <BB7627E9-8D50-48E5-B809-64AE4D574271@virtualized.org> <20131203221006.GB5689@sources.org> <D3E446D0-F9ED-4671-A1C2-29A15D3DE010@virtualized.org> <20131204094449.GA5492@nic.fr> <9650BF6D-727B-4EF3-B357-7E4E2FDDE0AF@virtualized.org> <2614C613-1399-429D-856B-5E2C18DCA7A6@kumari.net> <1DA98CD6C61144088EA480D71E51AF3D@hopcount.ca> <Prayer.1.3.5.1312051215460.21609@hermes-2.csi.cam.ac.uk>
To: "cet1@cam.ac.uk Thompson" <cet1@cam.ac.uk>
X-Mailer: Apple Mail (2.1822)
Cc: IETF DNSOP WG <dnsop@ietf.org>
Subject: Re: [DNSOP] [internet-drafts@ietf.org: I-D Action: draft-grothoff-iesg-special-use-p2p-names-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: Sat, 07 Dec 2013 21:52:21 -0000

On 2013-12-05, at 07:15, Chris Thompson <cet1@cam.ac.uk> wrote:

> On Dec 4 2013, Joe Abley wrote:
> 
> [...snip...]
>> There was at least one study commissioned by ICANN on the prudence of
>> provisioning DNAME RRs in the root zone that concluded that there was
>> no obvious danger, but remember that any novel RRTypes in the root zone
>> are going to need implementation time in the systems and processes
>> involved in root zone management, and such changes have proven in the
>> past to be neither quick nor easy.
> 
> How would such DNAMEs interact with use of BIND's "root-delegation-only"
> (or equivalents, if any, in other software)? Do we have any idea how
> widespread use of that option is?

I don't recall there ever being a time when the default behaviour of BIND9 was to insist on delegation-only behaviour from the *root* zone. As I remember those fun and exciting, lawyer-infested times the delegation-only behaviour was applied to all TLD zones, except those that were specified as needing to be otherwise. I presume this was an attempt to avoid calling out COM and NET explicitly.

Did I remember wrongly? Entirely possible ;-)

> When "ipv4only.arpa" appeared as a delegation in October, I did wonder
> why it wasn't just an A rrset in the "arpa" zone, until I thought of
> that issue. Although maybe the reasoning was actually different.

I was involved in that conversation. I promoted the idea of a delegation simply because the machinery behind the scenes was built to facilitate delegations rather than the addition of arbitrary records to the ARPA zone, and the corresponding processes were similarly delegation-centric. Implementing an apex A in a daughter zone seemed like the pragmatic answer, and the authors of the draft that requested ipv6only.arpa were happy to agree.


Joe