Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt

"Wessels, Duane" <dwessels@verisign.com> Mon, 20 May 2019 22:24 UTC

Return-Path: <dwessels@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3734612011D for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 15:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 gFc7I1p-L10e for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 15:24:53 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 1B2E012004B for <dnsop@ietf.org>; Mon, 20 May 2019 15:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9825; q=dns/txt; s=VRSN; t=1558391095; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=WWYXVK/9n5R22FkkZLWg6m92mPXAJbYIga4kt1pOnRY=; b=khwdT7y78Zoi1tqPTXEXy1XoxrQboMPuxyiRrldcdKYQ5Kxhrf6pVGfX Ooa9rUtmh34/MMDl7EbnGHo3ezsvcBroLr18qHDJps853YwYAByTQdQln 1S0FxP9bIOKA69kqxgspvvUabalFcZ9YGc4MTdpOgrI9zNgX6TBP86vKy tg/0ANR2gEctPaFd/4F9V4Y6BfYK+KgzkQZi1Qef3IAgpApV7GTw5QZNc IeeGXKZFGQlsKU9K+vT5AyeTVdelSlLf88H1CYU0HIoc/s13Gondxr2eY RAMvt+rWycD59ll4YD5EoSF8JV/ctKfe/sEbRXxJl6OVtW4IH6Nl+kZYv Q==;
X-IronPort-AV: E=Sophos; i="5.60,492,1549947600"; d="p7s'?scan'208"; a="7557685"
IronPort-PHdr: =?us-ascii?q?9a23=3Ac12CqBX6kXxPxtdZoDnzTBmlCs7V8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYbReHt8tkgFKBZ4jH8fUM07OQ7/m5HzVYsN3Z4DgrS99lb1?= =?us-ascii?q?c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUh?= =?us-ascii?q?rwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrsAndrNQajZdmJ6o+1h?= =?us-ascii?q?fEoWZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PW?= =?us-ascii?q?wt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WS?= =?us-ascii?q?in4qx2RhLklDsLOjgk+2zMlMd+kLxUrw6gpxxnwo7bfoeVNOZlfqjAed8WXH?= =?us-ascii?q?dNUtpNWyBEBI63cokBAPcbPetAr4fzuUYArQewCwevCuPgyD5IiWP50qAh3O?= =?us-ascii?q?QtDQTG0RY8E94SrnjZqsj+OqcIUeCyyanF1TvPYPNI1jfm84jHbBQhoeqUUb?= =?us-ascii?q?ltf8TR1FMgFwXbgVmetIfoOC6a1+oTvGiA9OpvS+avi3U8pgFvvDev3MYsip?= =?us-ascii?q?LIhoIazFDI7zl2wIEwJdChTkNwfN2qEINIui2HK4d6WN4uTmNmtSog17ELuZ?= =?us-ascii?q?C2cDIFxZkk3xLTduCLf5KV7h/hSOqdOyp0iX1mdb6lmhq/8lCsyuPiWcS3zF?= =?us-ascii?q?pHqy9IncPPu30JzBPe78aKRuVg8Uqg3DuAzATe5+BGLE0xm6fWJZwszaM2m5?= =?us-ascii?q?EOq0rMBDX2l1/zjKKOc0Uk/fWn5Pr/b7X9o5+cK5d0igbjMqQygsC/Afo3Mg?= =?us-ascii?q?wJX2WD5OmyyKXt8VD5T7tSgfM5k7XVvI3AKcQFuqG5BBVV0p455xmlEjiqys?= =?us-ascii?q?oYnWMcLFJDYh6Ik4/pO1TWLPD5C/ewnUisnS92y/zaJLHtH5fAI3bZnLv8fb?= =?us-ascii?q?tw5VRQxQUwwNxH4pJbELABIPb9Wk/rs9zYCwc0PBG6wun5E9V9zZ0RWWaUAq?= =?us-ascii?q?KCLqPdr0WI5uM0I+mNa48VvizxJOQi5/7rlXM5g0MSfbG13ZsLb3C1BvZmLF?= =?us-ascii?q?+CbnronNgAEXwHvgo5TOzylFKCViNTZ3CuX64m+j40EpqsDZ3fSYC1nLyBwC?= =?us-ascii?q?C7E4VLaWBAEVCMFm/oep6FW/gSdCKSLNVtkjseVbiuGMcd0kSMswKy4rBjI/?= =?us-ascii?q?ucri8Rv5buxfB14PXYkgw06Xp/BpLO/XuKSjQ+oW4TXDIyx+Q3jVF0zFrJmf?= =?us-ascii?q?x0nPFDDtFX/NtXXx07Lp/TyapxDNWkCVGJRcuAVFvzGobuOjo2VN9khoZWO0?= =?us-ascii?q?s=3D?=
X-IPAS-Result: =?us-ascii?q?A2FPAADoKONc/zCZrQplGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?YFigRiBLAqHU5ErJYNelnIJAQEBAQEBAQEBAwQBGxQBAYEER4J1AoJgOBMBA?= =?us-ascii?q?wEBAQQBAQEBAwEBAQKBBQyCOikBgUssDSY9AQEBAQIBeQULAgEIDgouAjAlA?= =?us-ascii?q?gQOBQ6DFAGBe6g3g3U+AYEUhGIQgTSBT4oZgUE+gTgME4JMPoJhBIE3ZoJ+g?= =?us-ascii?q?iYEi1+HEJUpAwYCgg2DE4IYgQOMYgeCHZQCjXeQQ4NTAgQCBAUCFYFmgXlwF?= =?us-ascii?q?WUBgkEJhCWMI3IBjAOBIoEhAQE?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 20 May 2019 18:24:47 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Mon, 20 May 2019 18:24:47 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Joe Abley <jabley@hopcount.ca>
CC: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
Thread-Index: AQHVDwACn824ZuGnpk+9CuOW9VlEwaZ02rYA
Date: Mon, 20 May 2019 22:24:47 +0000
Message-ID: <E1216FE6-A45D-41E3-9534-73C36047C871@verisign.com>
References: <155009468256.9559.12509906855495134896@ietfa.amsl.com> <923006F8-EB5A-4098-81A2-782BC90BF220@verisign.com> <CAAiTEH_GmvNVgAZzwG+oaQrtNd_b=kpDSRz7ErbmTjuXrzziWg@mail.gmail.com> <CABrJZ5FBYpFrjpm-a+B9FF8rbVNXwy=V-MP0TPS8fG87OJeteg@mail.gmail.com> <0E8CD2BB-C8C6-4387-8FAD-DAC84B381557@verisign.com> <C6FAC979-BAF6-4DFC-8493-5872E7FB787D@hopcount.ca>
In-Reply-To: <C6FAC979-BAF6-4DFC-8493-5872E7FB787D@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_7F57D276-B99E-4EC2-956D-59CCD8253042"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6VKvky3sxpn8ijbyRD44zLy1jkY>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 20 May 2019 22:24:55 -0000


> On May 20, 2019, at 4:34 AM, Joe Abley <jabley@hopcount.ca>; wrote:
> 
> Hi Duane,
> 
> (Olli's message just bumped this thread up in my inbox, so it's an enormously late reply but not for me, if you see what I mean)
> 
> On 25 Mar 2019, at 17:15, Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org>; wrote:
> 
>> I'm not aware of anything that could be enabled by non-apex ZONEMD records. My preference would be to forbid non-apex ZONEMD records.
>> 
>> I guess my concern was just that it means implementors need to check for this and treat the RR type somewhat specially, as they do for SOA and maybe a couple other RR types.
> 
> I don't actually see any benefit to forbidding anything, and I don't know what "forbid" would mean in this instance.
> 
> I think there's a ready analogy of the former in PTR records. I can put a PTR record in a zone whose apex owner name doesn't end in "in-addr.arpa" or "ip6.arpa". It's not forbidden. It's occasionally useful, since I can put CNAMEs in the reverse tree in zones managed by other people and not have to bother them when I want to update the mapping. CNAMEs are not a good example in the case of ZONEMD, but perhaps there are other future operational tricks that might come to light that are not obvious today. In any case, putting a ZONEMD RRSet somewhere other than an apex doesn't do any harm.
> 
> As to the meaning of "forbid", if there's an implication that such a prohibition should be enforced somewhere (in zone parsers, in nameservers, in stub resolvers, somewhere) then I am against it. :camel_wagging_finger_and_shaking_head_sadly:
> 
> Maybe there's actually an operational use-case here, actually, in the case where you're removing a zone cut. Perhaps you want to preserve a low-TTL ZONEMD RRSet at the place where the zone cut was in the superset zone to accommodate zone distribution graphs that are slow (e.g. across badly-connected networks). This is a bit of a stretch and I haven't thought it through very well, but I think it's a bigger stretch to assert that there is definitively no use for this, especially if leaving the door open is free and bolting it shut is expensive.


Thanks for the feedback, Joe.  

To me SOA is a better example than PTR.  I know some software will complain or refuse to load a zone that has a non-apex SOA, but I also expect there is software out that there accepts/allows it.  DNS seems to have a small number of other apex-only records, but I doubt they are strictly forbidden.

Personally I think a strict, rather than liberal, approach would be better, but I'm not opposed to allowing non-apex records.

Here's what the current (not-yet-published) draft now says:

2.1.  ZONEMD Location

   This specification utilizes ZONEMD RRs located at the zone apex.
   Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
   specification.

DW