Re: [DNSOP] zone contents digest and DNSSEC stuff

Joe Abley <> Tue, 29 September 2020 13:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 190653A0B2A for <>; Tue, 29 Sep 2020 06:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 6UU3UMN3ThiX for <>; Tue, 29 Sep 2020 06:03:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDF213A0A1D for <>; Tue, 29 Sep 2020 06:03:23 -0700 (PDT)
Received: by with SMTP id c2so4151323qkf.10 for <>; Tue, 29 Sep 2020 06:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=AoArTFfbgxwQKKealxKWul7f+BFnYneR5LG26hHe1iU=; b=ixaU2nwapp/8hNf3KCcXC59ViWxKaBRo0NTwqLwsxWBk9Nv3E269aHNmKk8ikZ+PNF wmdoRvtjavslcjaAvxpDAePbu1navTCWYEhQmoOC+qcavWucL8WiPWqYv5JPlshVxJab JkZgo14mxBXzOGg8JdAKF3liiYPs/7bY/7S6Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=AoArTFfbgxwQKKealxKWul7f+BFnYneR5LG26hHe1iU=; b=YStwsDd0Ze/pj0RI0KCtMzg6Frv/S7PSZTJXUlPHJQZwl6L7Rv+N8Hrb7allln1Joh UWqd/ax3pTiM8RQf5v6FKhQ/JKaHucQtKIJzomBy7kM990eZgUMoYaRxDmKW2ZWgKJ28 D8D0S4gzNwRhwsdENL9ot9aP+HMpM45LQXfE9SX4nzRCDThd4STExUi8bQTGtN4+DTdZ IjRXtvPh92f/auvCUJlrGoeNQpCu2Od8erF0+INOXd5+hlPq58LLX5wKB0ntxOra18Py ckYAQJpMoxA4b5Jzile++9Ypv5BCV5Qec5ZvaP1fwZ8IeIneDaSlzUfQpEa9Q+cHR+ty azXA==
X-Gm-Message-State: AOAM530xqqdxFWHu1BRnsa/n94XJGRyOqKuJBAfrQjlRX6rEvKnc4PlZ tigT1qYQvHnfIxVbze9UTILDdH3CxSDaae7VX2s=
X-Google-Smtp-Source: ABdhPJyc8iJIW+u9K5J1VAvAgTt8DM03weu8nzafpjgQO80eSIWF92eXFP8AI8fLEFtczbfroCLmxQ==
X-Received: by 2002:a37:a887:: with SMTP id r129mr3902386qke.263.1601384602202; Tue, 29 Sep 2020 06:03:22 -0700 (PDT)
Received: from localhost.localdomain ([2607:f2c0:e784:c7:f5b1:e5c6:9b7:ec49]) by with ESMTPSA id x25sm5028188qtp.64.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Sep 2020 06:03:20 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Joe Abley <>
In-Reply-To: <>
Date: Tue, 29 Sep 2020 09:03:19 -0400
Message-Id: <>
References: <>
To: "libor.peltan" <>
X-Mailer: iPad Mail (18A373)
Archived-At: <>
Subject: Re: [DNSOP] zone contents digest and DNSSEC stuff
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: Tue, 29 Sep 2020 13:03:25 -0000

Hi Libor,

On Sep 29, 2020, at 05:51, libor.peltan <> wrote:

> Often the zone operators work with both un-signed and signed "versions" of their zone. The un-signed version usually comes from a registry system or a database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip DNSSEC-related records from signed zone, if needed.
> I feel like it would be equally useful to maintain a digest of the un-signed and signed version of the zone, respectively.

Others may have different ideas about this, but to me it makes the most sense for a particular zone that contains a ZONEMD RRSet to use it to carry a checksum of itself, not some other zone. 

The unsigned zone, as you have described it, is a different zone from the signed zone; it contains different resource records. It could contain its own ZONEMD RRSet, but that would reflect its own checksum. Since it's unsigned, its ZONEMD would also have no authenticity protection, but there could be internal, trusted environments where that was not a concern and the unsigned ZONEMD could still be useful.

For example, you could still compute a ZONEMD for an unsigned zone in order to use it to check that the zone was intact within the internal registry/signer machinery. You would replace it with a newly-computed ZONEMD once the zone had changed through the process of signing (the new ZONEMD reflects those changes).

The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough?