On 1/15/2020 8:39 PM, Paul Hoffman wrote:
On Jan 15, 2020, at 5:28 PM, Michael StJohns <m...@nthpermutation.com> 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);
break;
case INCREMENTAL:
processIncrementalZoneMD(rr);
break;
default:
error();
}
}
vs
switch (rr.rrtype) {
case ZONEMD:
processSimpleZoneMD(rr);
break;
case INCZONEMD:
processIncrementalZoneMD(rr);
break;
}
Not really sure where you think why one might be safer than another.
Later, Mike
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
