[DNSOP] zone contents digest and DNSSEC stuff

"libor.peltan" <libor.peltan@nic.cz> Tue, 29 September 2020 09:51 UTC

Return-Path: <libor.peltan@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A60B83A0AAB for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 02:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2QIDFWB5coZy for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 02:51:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 1DDF63A0AA6 for <dnsop@ietf.org>; Tue, 29 Sep 2020 02:51:13 -0700 (PDT)
Received: from [] (unknown []) by mail.nic.cz (Postfix) with ESMTPSA id 35AE1140AA4 for <dnsop@ietf.org>; Tue, 29 Sep 2020 11:51:09 +0200 (CEST)
To: dnsop@ietf.org
References: <160106456118.31789.11961383115680685040@ietfa.amsl.com>
From: "libor.peltan" <libor.peltan@nic.cz>
Message-ID: <4553c77e-9333-1002-d06e-e9ad10857290@nic.cz>
Date: Tue, 29 Sep 2020 11:51:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <160106456118.31789.11961383115680685040@ietfa.amsl.com>
Content-Type: text/plain; charset="iso-8859-2"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/z3XS5SCGWfNXxCqVJPxdKwcIj8E>
Subject: [DNSOP] zone contents digest and DNSSEC stuff
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: Tue, 29 Sep 2020 09:51:18 -0000


I don't fully know the background of this topic, so my question might be 

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.

Does the calculation of ZONEMD include the DNSSEC-related records? Have 
you maybe thought about including two such records, for both cases?

Thanks for comments,


Dne 25.09.20 v 22:09 internet-drafts@ietf.org napsal(a):
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>          Title           : Message Digest for DNS Zones
>          Authors         : Duane Wessels
>                            Piet Barber
>                            Matt Weinberg
>                            Warren Kumari
>                            Wes Hardaker
> 	Filename        : draft-ietf-dnsop-dns-zone-digest-11.txt
> 	Pages           : 36
> 	Date            : 2020-09-25
> Abstract:
>     This document describes a protocol and new DNS Resource Record that
>     provides a cryptographic message digest over DNS zone data.  The
>     ZONEMD Resource Record conveys the digest data in the zone itself.
>     When a zone publisher includes a ZONEMD record, recipients can verify
>     the zone contents for accuracy and completeness.  This provides
>     assurance that received zone data matches published data, regardless
>     of how the zone data has been transmitted and received.
>     ZONEMD does not replace DNSSEC.  Whereas DNSSEC protects individual
>     RRSets (DNS data with fine granularity), ZONEMD protects a zone's
>     data as a whole, whether consumed by authoritative name servers,
>     recursive name servers, or any other applications.
>     As specified herein, ZONEMD is impractical for large, dynamic zones
>     due to the time and resources required for digest calculation.
>     However, The ZONEMD record is extensible so that new digest schemes
>     may be added in the future to support large, dynamic zones.
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-11
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-zone-digest-11
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-zone-digest-11
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop