This is to document what I said to Matthijs in the hallway after the presentation.
As a source of data on the problem - look at IXFR traffic supporting a zone to see what's being deleted that doesn't need to be explicitly stated. It's obvious that changing any set invalidates the RRSIGs on it. (Not from the conversation) When refreshing RRSIGs, the incumbent ones might deserve deleting. Back in the day we imagined that an RRSET might include signature good on Monday and a different one on Tuesday, etc., so the protocol does not limit the set of signatures for owner, type, class, dnssec-algorithm, footprint to 1. OTOH, what we imagined in this regard is not a realistic use, today sets usually sport just one RRSIG at a time. Given this - when an RRSIG is added, questionably matching (for some definition of matching) RRSIGs should be deleted. It's not to obvious whether the addition of an NSEC3PARAM record implies the desire to delete NSEC3 records with different salt (or other parameters). Adding NSEC3's might mean a new chain is being installed (as in a salt change), but until the NSEC3PARAM, it isn't the active or necessarily a complete chain. Ultimately, if MIXFR can identify all records that should suffer an implied delete, then this is an improvement over IXFR in terms of saving message size. Operators don't often look at IXFR traffic, so I discount the idea that implicit actions is a problem here - so long as the change logs show what is deleted due to an implicit MIXFR assumption. I think examining live IXFR flows found in real operations would be very helpful in tuning the implicit delete heuristics that can be employed.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
