Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

Michael StJohns <> Wed, 08 January 2020 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A526A12013B for <>; Wed, 8 Jan 2020 11:32:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 q1dMkhplCNz0 for <>; Wed, 8 Jan 2020 11:32:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60F201200CC for <>; Wed, 8 Jan 2020 11:32:02 -0800 (PST)
Received: by with SMTP id j9so3767286qkk.1 for <>; Wed, 08 Jan 2020 11:32:02 -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=0IHK3TTN9PqeYTLxJS73a0oZxjBNGYVYPhg6NWnd7Cs=; b=jRgu27V4NweSteVcyWC9aNriPcHowWx1Cs6xMJrOCGlzxbug1cuxVOdWuD6r0Rltnv gauwwn6pL3kJ8NAXjfHYJtIeTpwGI4NEYe5ChBKSxQXlG/dGELxW2OMl619ROBSBjSSt Xd6ikofb1K4gvxcT1ras1M099xTaIary5InRbZ0XVeAZGzFMui2Dd0qjRSU6VA9OUGKm j/NY+amtmycwdwVkmReLdIdMBBKKvwC4VXYtUsIY9tzGVJzFOQRLa/UTWrz44HMI1zyh l6lkFwM8TNeRLbNrK/9txhmLvoacAv6vbD/8wyNEsJ067HdJ2+10NgEjCOT7+LjfJYnC X/ow==
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=0IHK3TTN9PqeYTLxJS73a0oZxjBNGYVYPhg6NWnd7Cs=; b=AJXk1r2apFcMEwnr4mSLlHXzRaJ69yzmZTJgQPuMs/mDlS9OVO+TH2N7LG2dpklXny hql6dvlZIbJdVGwKkEOTFvELLtQ5aLQ0xrzF7mM+USfub2w5tHMePElDPaLFTw67WXA3 HMamn9K8yXdC+J/c8gdNNz1NVMMArT4YwGsCA443k16FanskVUXbQljr6gl6Os7d0gaG Vjllcu+VoNmhw5ARt+Ct2wPBBTrABlHAQdHmsKVAOt/lf/ogYDBgKRE2Qb0qTxlav+Xd YvRIPW5n8XVpkOj2PFmhQxGPb+iVTvvBsXHH6fZ22WrfYOUck0eomhN/Q2r8mbHjzfEi 4TwQ==
X-Gm-Message-State: APjAAAU/BeiuBihgEZs+ki+1wGfmUzbT0hYn4Wc8dhBQMCq7QElVyXg7 Y9pJMxCpBCwvdpHWkVKLYeK9dVENf5s=
X-Google-Smtp-Source: APXvYqzyIqrhXe38SlyNu7QJb4pUkEXpyfCBFNIiRZZK0HjUynQ1MmMFUDr1U4Q+whSBCKqL7wqBOA==
X-Received: by 2002:a37:a02:: with SMTP id 2mr5723561qkk.111.1578511921104; Wed, 08 Jan 2020 11:32:01 -0800 (PST)
Received: from ?IPv6:2601:152:4400:437c:dd4:4ade:7d8:f573? ([2601:152:4400:437c:dd4:4ade:7d8:f573]) by with ESMTPSA id q25sm1892848qkq.88.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 11:32:00 -0800 (PST)
To: "Wessels, Duane" <>
Cc: "" <>
References: <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Wed, 8 Jan 2020 14:31:59 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.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] 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: Wed, 08 Jan 2020 19:32:04 -0000

On 1/7/2020 6:38 PM, Wessels, Duane wrote:
>> On Jan 6, 2020, at 6:15 PM, Michael StJohns <> wrote:
>>>>>     This specification utilizes ZONEMD RRs located at the zone apex.
>>>>>     Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
>>>>>     specification.
>>>> Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".
>>> The current text was agreed to during earlier working group discussion.  The problem with "ignore" (as John points out) is that it could mean the non-apex RR should be omitted from the zone.
>>> At one point the document said that non-apex ZONEMD was forbidden, with the implication that if found the whole zone should be rejected.  Similar to what you might do with a non-apex SOA.  But that seemed pretty harsh and in the end we settled on the current text.
>> Your text "have no meaning in this specification" doesn't actually tell me what to do when I receive a non-apex ZONEMD RR. Maybe instead "Receivers SHALL NOT attempt to validate non-apex ZONEMD RRs.  All other validation rules apply (e.g. inclusion in the HASH using the actual value)"....
> How about this:
> 2.1.  Non-apex ZONEMD Records
>     This specification utilizes ZONEMD RRs located at the zone apex.
>     Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
>     specification.  Non-apex ZONEMD RRs MUST NOT be used for
>     verification.  Non-apex ZONEMD RRsets are treated like any other
>     RRset (which is to say they are included) during digest calculation.
>     Unless explicitly stated otherwise, "ZONEMD" always refers to apex
>     records throughout this document.
WFM and quite a bit clearer.
>> Assume that someone will screw up and place a ZONEMD RR where it shouldn't be.  Figure out what that does to the validation process.   Is it included in the hash?  If so, does it get included with the actual value of its fields or using the placeholder format?  Or do you check it both ways?
> Yes, in fact I myself made this mistake when testing my implementation.  It's why there is a non-apex ZONEMD record in example A.2.
> DW
My point exactly!   I'm not a big fan of ambiguity in protocol 
definitions as you may guess.

Thanks - Mike