Tony Finch authored Jan 14, 2020 and Mark Andrews committed Jan 21, 2020

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 `syncpublish()`
logic, because the future key's sync records appear early. With the
new `syncpublish()` logic the future key does not affect the test, as
expected, and it now passes.