Hi Libor, On Sep 29, 2020, at 05:51, libor.peltan <libor.pel...@nic.cz> wrote:
> Often the zone operators work with both un-signed and signed "versions" of > their zone. The un-signed version usually comes from a registry system or a > database, whereas a "signer" server adds "the DNSSEC stuff", like DNSKEYs, > RRSIGs, NSECs, etc. It's also usually possible to do the reverse: strip > DNSSEC-related records from signed zone, if needed. > > I feel like it would be equally useful to maintain a digest of the un-signed > and signed version of the zone, respectively. Others may have different ideas about this, but to me it makes the most sense for a particular zone that contains a ZONEMD RRSet to use it to carry a checksum of itself, not some other zone. The unsigned zone, as you have described it, is a different zone from the signed zone; it contains different resource records. It could contain its own ZONEMD RRSet, but that would reflect its own checksum. Since it's unsigned, its ZONEMD would also have no authenticity protection, but there could be internal, trusted environments where that was not a concern and the unsigned ZONEMD could still be useful. For example, you could still compute a ZONEMD for an unsigned zone in order to use it to check that the zone was intact within the internal registry/signer machinery. You would replace it with a newly-computed ZONEMD once the zone had changed through the process of signing (the new ZONEMD reflects those changes). The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough? Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
