This is a bug I encountered when trying to schedule an algorithm rollover. My plan, for a zone whose maximum TTL is 48h, was to sign with the new algorithm and schedule a change of CDS records for more than 48 hours in the future, roughly like this:
$ dnssec-keygen -a 13 -fk -Psync now+50h $zone $ dnssec-keygen -a 13 $zone $ dnssec-settime -Dsync now+50h $zone_ksk_old
However the algorithm 13 CDS was published immediately, which could have made the zone bogus.
To reveal the bug using the
smartsign test, this change just adds a
KSK with all its times in the future, so it should not affect the
existing checks at all. But the final check (that there are no CDS or
CDSNSKEY records after -Dsync) fails with the old
logic, because the future key's sync records appear early. With the
syncpublish() logic the future key does not affect the test, as
expected, and it now passes.