Tony Finch authored Jun 22, 2020 and Mark Andrews committed Jul 14, 2020

Since October 2019 I have had complaints from `dnssec-cds` reporting
that the signatures on some of my test zones had expired. These were
zones signed by BIND 9.15 or 9.17, with a DNSKEY TTL of 24h and
`sig-validity-interval 10 8`.

This is the same setup we have used for our production zones since
2015, which is intended to re-sign the zones every 2 days, keeping
at least 8 days signature validity. The SOA expire interval is 7
days, so even in the presence of zone transfer problems, no-one
should ever see expired signatures. (These timers are a bit too
tight to be completely correct, because I should have increased
the expiry timers when I increased the DNSKEY TTLs from 1h to 24h.
But that should only matter when zone transfers are broken, which
was not the case for the error reports that led to this patch.)

For example, this morning my test zone contained:

        dev.dns.cam.ac.uk. 86400 IN RRSIG DNSKEY 13 5 86400 (
                                20200701221418 20200621213022 ...)

But one of my resolvers had cached:

        dev.dns.cam.ac.uk. 21424 IN RRSIG DNSKEY 13 5 86400 (
                                20200622063022 20200612061136 ...)

This TTL was captured at 20200622105807 so the resolver cached the
RRset 64976 seconds previously (18h02m56s), at 20200621165511
only about 12h before expiry.

The other symptom of this error was incorrect `resign` times in
the output from `rndc zonestatus`.

For example, I have configured a test zone

        zone fast.dotat.at {
                file "../u/z/fast.dotat.at";
                type primary;
                auto-dnssec maintain;
                sig-validity-interval 500 499;
        };

The zone is reset to a minimal zone containing only SOA and NS
records, and when `named` starts it loads and signs the zone. After
that, `rndc zonestatus` reports:

        next resign node: fast.dotat.at/NS
        next resign time: Fri, 28 May 2021 12:48:47 GMT

The resign time should be within the next 24h, but instead it is
near the signature expiry time, which the RRSIG(NS) says is
20210618074847. (Note 499 hours is a bit more than 20 days.)
May/June 2021 is less than 500 days from now because expiry time
jitter is applied to the NS records.

Using this test I bisected this bug to 09990672 which contained a
mistake leading to the resigning interval always being calculated in
hours, when days are expected.

This bug only occurs for configurations that use the two-argument form
of `sig-validity-interval`.

(cherry picked from commit 030674b2)