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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to