Skip to content

Fix re-signing when `sig-validity-interval` has two arguments

Tony Finch requested to merge fanf/bind9:u/fanf2/fix-signing into main

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.

Edited by Mark Andrews

Merge request reports