Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)

Michael StJohns <> Thu, 16 January 2020 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71A28120A6E for <>; Thu, 16 Jan 2020 08:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bQmAXfcYbfvu for <>; Thu, 16 Jan 2020 08:46:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E151C120842 for <>; Thu, 16 Jan 2020 08:46:47 -0800 (PST)
Received: by with SMTP id d15so1788761pjw.1 for <>; Thu, 16 Jan 2020 08:46:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=z8kRSPbo7PxMY+GFuUDZvM8P6AOzqNEqfNu2QIt1CcA=; b=k0Z+Ix3TyIItX+RvI23p/uH2Bmg/tBDMWreYS6jitlLnB6JpGZps3jYUe5YGLnL3rX diTlN3XhQmHc25v77ySZOBYfLxIcAjrC8enaKVSHWzXYkL9aEzCQPxI1FKEkmNC8jjGO YM4TbPvF7L+6PKg1dYz0N0oS3GngMzANg1fGZBLLx7cRFT3wD46+jDitzGyeX91bsWWP FrNzbM2/cFv894j1u7TH31nf2I2EcQ4IV7gbW93Z70rdlnJ+kfmpEQOqIbUfsa7PbBbJ /85zTDj7TUzMkvzVsMVX5RGEAD0IMghy9E6oXsWyGe6to2MQJ1Ls3tK1VO1jvxo5K3ao e9mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=z8kRSPbo7PxMY+GFuUDZvM8P6AOzqNEqfNu2QIt1CcA=; b=rkJkWPoHAJDStpXq5RODX1KKenNwAFXIXpjtU97xubEsuFcre1+a462xkyxVmPHPsn xVeuUr1D1nWLX3GHDFqGCi94hi1p7ZzskcPgTCqYvSv1sLs5cfI82DRb5ZCE9TEMIOgL G5XxqPurJOxq95cJDn2WauK3DwuuKB4IlugBLXeLdVLcByr6aSFzUdLLc9cvUl8xDR3P Ajb5Ottg7nz4+OMsvX83kLQ7qKcyuBAFoidgqerDVx1jiRdVPoHWw4hmQB7DG/R4nU+k f9yRKz3vUxNMSeLN+Ji+mntpZt8uHM0dCskgNAre9kqNCFO26gVdQg8nhIX1MP5M7SKm RS2g==
X-Gm-Message-State: APjAAAUgruACIKfGGMbA+jhobP0axoo+g2iF3GZc5NZbp8X3H2vtXIN4 bsEKk41dkSyVZs4J+yHPEykqq6B4Wsc=
X-Google-Smtp-Source: APXvYqyDCxbcVg6s0oea8ai9HOMKjwka9Z1SVMGjO4blrdyA6rqJI7SDQNdJgnFRPaP14QOq3Qm2Pw==
X-Received: by 2002:a17:902:9b94:: with SMTP id y20mr26368982plp.291.1579193207019; Thu, 16 Jan 2020 08:46:47 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id a17sm4230642pjv.6.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2020 08:46:46 -0800 (PST)
To: Paul Hoffman <>
Cc: "" <>
References: <> <> <> <28189634.PH2fhW1m7e@linux-9daj> <> <> <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 16 Jan 2020 11:46:45 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] [Ext] future-proofing (Re: Working Group Last Call for: Message Digest for DNS Zones)
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: Thu, 16 Jan 2020 16:46:55 -0000

On 1/15/2020 8:39 PM, Paul Hoffman wrote:
> On Jan 15, 2020, at 5:28 PM, Michael StJohns <> wrote:
>> I think its a co-existence issue here.  I don't think you should have two different (calculation-wise) ZONEMD-like RRSets in the same zone for the reasons you've mentioned.
> That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD.

That doesn't really deal with the problem.  ZONEMD (this document) 
really needs to have similar language, otherwise changing from ZONEMD to 
whatever could cause issues for the receiver. What you want is for both  
(many) to be able to coexist and ignore each other  - IMHO.

>> I don't think that reserving RR types is the right way of doing things and I'm not sure how you'd write the IANA guidance to cover the later assignment of those type numbers.
> Fully agree.
>>   It's possible that we can tweak this a bit and get around the problem.
>> So maybe:
>> 1 byte - Scheme - 1 == SIMPLE
>> Which has a body of
>> 1 byte - digest - 1 == SHA384, a
>> followed by N bytes of the appropriate digest length.
> Using a different RRtype would be significantly easier and safer due to applications having clearly separate code paths.

The two different code paths are (pseudocode):

switch (rr.rrtype) {

   case ZONEMD:
           switch (((zonerr)rr).scheme) {
               case SIMPLE:
                    processSimpleZoneMD (rr);
               case INCREMENTAL:




switch (rr.rrtype) {
     case ZONEMD:
     case INCZONEMD:


Not really sure where you think why one might be safer than another.

Later, Mike

> --Paul Hoffman