On 1/7/2020 6:38 PM, Wessels, Duane wrote:
On Jan 6, 2020, at 6:15 PM, Michael StJohns <m...@nthpermutation.com> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
