Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 585
    • Issues 585
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 112
    • Merge Requests 112
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • BINDBIND
  • Merge Requests
  • !3735

Merged
Opened Jun 22, 2020 by Tony Finch@fanfContributor

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

  • Overview 3
  • Commits 4
  • Pipelines 7
  • Changes 7

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 Jul 14, 2020 by Mark Andrews
Assignee
Assign to
Reviewer
Request review from
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)
Milestone
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4) (Past due)
Assign milestone
Time tracking
Reference: isc-projects/bind9!3735
Source branch: u/fanf2/fix-signing

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.