> 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. > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
