Given an already signed upstream, the AXFRs we receive contain DNSSEC RRs. During normal operation of Cascade these get kept in memory in the loaded instance and subsequent IXFRs that attempt to replace DNSSEC RRs succeed because they exist in the loaded instance and so attempts to remove a DNSSEC RR that was removed at the upstream succeed. Even a restart of Cascade is fine as the persisted loaded diff also contains the upstream DNSSEC RRs.
A problem occurs with restore after compaction in the case of a signed upstream. Compaction periodically replaces the stored zone snapshots with newer versions if some of the persisted diffs are no longer wanted (as they exceed the max_diffs or max_diffs_size policy settings). The replacement snapshots are written out by writing the loaded and signed records from the current published version to snapshot files on disk. The problem is that the loaded part of the published version of the zone does NOT include the upstream DNSSEC RRs so the newly persisted snapshot suddenly lacks loaded DNSSEC RRs that it previously had. When that snapshot is restored and then an upstream IXFR is received, if that IXFR replaces upstream DNSSEC RRs those RRs no longer exist in our loaded copy of the zone and diff application is strict so rejects the attempt to apply a mismatched operation to the current copy of the zone.
I could write out the new snapshot differently during compaction, i.e. by loading the previously persisted loaded snapshot into memory and loading each previously persisted loaded diff and applying it to the temporarily loaded old snapshot in order to build a new current loaded snapshot that still includes the upstream DNSSEC RRs, then write that out to disk. I didn't do that until now because it would require using a lot more memory, and I didn't account for loaded data already including DNSSEC RRs.
I guess we need to support already signed data for the passthrough case. I did a quick hack to test and ignoring the attempt to remove non-existing records during diff application "solves" the problem. However then an incorrect IXFR that tries to wrongly delete a record that really doesn't exist would be tolerated. And the loaded review server diff would not show the expected DNSSEC RR removal.
Given an already signed upstream, the AXFRs we receive contain DNSSEC RRs. During normal operation of Cascade these get kept in memory in the loaded instance and subsequent IXFRs that attempt to replace DNSSEC RRs succeed because they exist in the loaded instance and so attempts to remove a DNSSEC RR that was removed at the upstream succeed. Even a restart of Cascade is fine as the persisted loaded diff also contains the upstream DNSSEC RRs.
A problem occurs with restore after compaction in the case of a signed upstream. Compaction periodically replaces the stored zone snapshots with newer versions if some of the persisted diffs are no longer wanted (as they exceed the
max_diffsormax_diffs_sizepolicy settings). The replacement snapshots are written out by writing the loaded and signed records from the current published version to snapshot files on disk. The problem is that the loaded part of the published version of the zone does NOT include the upstream DNSSEC RRs so the newly persisted snapshot suddenly lacks loaded DNSSEC RRs that it previously had. When that snapshot is restored and then an upstream IXFR is received, if that IXFR replaces upstream DNSSEC RRs those RRs no longer exist in our loaded copy of the zone and diff application is strict so rejects the attempt to apply a mismatched operation to the current copy of the zone.I could write out the new snapshot differently during compaction, i.e. by loading the previously persisted loaded snapshot into memory and loading each previously persisted loaded diff and applying it to the temporarily loaded old snapshot in order to build a new current loaded snapshot that still includes the upstream DNSSEC RRs, then write that out to disk. I didn't do that until now because it would require using a lot more memory, and I didn't account for loaded data already including DNSSEC RRs.
I guess we need to support already signed data for the passthrough case. I did a quick hack to test and ignoring the attempt to remove non-existing records during diff application "solves" the problem. However then an incorrect IXFR that tries to wrongly delete a record that really doesn't exist would be tolerated. And the loaded review server diff would not show the expected DNSSEC RR removal.