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

Joe Abley <jabley@hopcount.ca> Mon, 20 May 2019 11:34 UTC

Return-Path: <jabley@hopcount.ca>
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 D0CFC120188 for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 04:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 F5_qVg_UrxZK for <dnsop@ietfa.amsl.com>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 663FE120184 for <dnsop@ietf.org>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
Received: by mail-it1-x143.google.com with SMTP id 9so22512021itf.4 for <dnsop@ietf.org>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o/AFCt3DtH0Pc++NRorojHLKu56KeVwyefZNKTAYzX0=; b=franlg98JZDEq5nbQYj0i860wEtt+aBcmJqbdbp6QY158dPHF8SVL9A8++TZTcqV7z DBFpGOPuJSGhwWgPAibLX+OqZU2nWokE7+L2DI3xvZytA4whHf0pdIeXrB/TgAHuovct RvqH5bbJN3tZG3gBQnkjI+2gmZMug91ytCTUA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=o/AFCt3DtH0Pc++NRorojHLKu56KeVwyefZNKTAYzX0=; b=aSTWhEFhGgg0od8Q8MPtITE+HcWgCE33dOBequNdRhliPnSoHM0DY6/YdR//wl/aPi AVe3+m4mY5h9vJEuCgJIE1lxaYl2qz07Wi290Zq6Tf+hXTACe1rZvSi+bCZaTqKWLqIs XMrHNFK9+Tw3U7H1qDKIdHnBobsTFeV7Lc2Gq+/DU7ys4unTD349GQJoaZvLEfkM0Y2Q DJZSPZ0Hyar/y4lyNlDlx/Nw2/OEJNzZrxxZRLAKUdvKXgehpUIE7k0bIFXn7rhp1DLZ VcbaxdwZegKeGSbWl2WnJFPxC9LhkqT3bwGFOdeSJzP74lz4UQACJM97+GS5fJ1U2I5N LU0A==
X-Gm-Message-State: APjAAAUCQlyEwsuPTHiWXEIFNT003mk+zd3Fr5M1H0o4MjJGBaV34RXy c/7IBa2KW2yzLB+2npBwSQ25xg==
X-Google-Smtp-Source: APXvYqya36z8k1qN6Cm5AsADFfgfBRs+JoBl59qy+Aah5LhD6DN5N/qMrCHkQowDYZzyK+9WBNVrVQ==
X-Received: by 2002:a24:2489:: with SMTP id f131mr16141015ita.14.1558352070510; Mon, 20 May 2019 04:34:30 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e786:128f:bdd3:7520:4c6:2146? ([2607:f2c0:e786:128f:bdd3:7520:4c6:2146]) by smtp.gmail.com with ESMTPSA id l13sm4192486iti.6.2019.05.20.04.34.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 04:34:29 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <C6FAC979-BAF6-4DFC-8493-5872E7FB787D@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_246355CE-069B-44BF-8666-0633FB1A90AD"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 20 May 2019 07:34:25 -0400
In-Reply-To: <0E8CD2BB-C8C6-4387-8FAD-DAC84B381557@verisign.com>
Cc: Olli Vanhoja <olli@zeit.co>, Matthew Pounsett <matt@conundrum.com>, "dnsop@ietf.org" <dnsop@ietf.org>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
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>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/E-zQu7CevvCmRYc-7l-AVHFUZw8>
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 11:34:33 -0000

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.


Joe