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

[Michael StJohns <[e-mail]>]

On 1/7/2020 6:38 PM, Wessels, Duane wrote:
>
>> On Jan 6, 2020, at 6:15 PM, Michael StJohns <[e-mail]> 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