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

Joe Abley <> Mon, 20 May 2019 11:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0CFC120188 for <>; Mon, 20 May 2019 04:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F5_qVg_UrxZK for <>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 663FE120184 for <>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
Received: by with SMTP id 9so22512021itf.4 for <>; Mon, 20 May 2019 04:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with ESMTPSA id l13sm4192486iti.6.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 04:34:29 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
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: <>
Cc: Olli Vanhoja <>, Matthew Pounsett <>, "" <>
To: "Wessels, Duane" <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-wessels-dns-zone-digest-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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 "" or "". 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.