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 591
    • Issues 591
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 113
    • Merge Requests 113
  • 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
  • Issues
  • #1256

Closed
Open
Opened Oct 02, 2019 by Shumon Huque@shuque

Signature Expiration Jitter not working for dynamic NSEC3 zones

Summary

For auto-dnssec zones, on initial signing, BIND should be jittering the signature expirations across the signature validity period. It does this correctly for NSEC zones. But not for NSEC3 zones that were provisioned by dynamically updating an NSEC3PARAM record into the zone.

BIND version used

BIND 9.14.4 (Stable Release) id:ab4c496

(As far as I can tell this affects previous versions of BIND too, back to the 9.12.x release that introduced the jitter feature. It is certainly present in 9.12.3, which we were running prior to 9.14.4.)

Steps to reproduce

  • Create a new zone with a decent number of records.
  • Create zone stanza in named.conf with "auto-dnssec maintain" and any sig validity parameters you want to set
  • rndc reconfig
  • Use DNS UPDATE to add an NSEC3PARAM record into the zone
  • Create DNSSEC keys in the zone directory
  • Trigger zone signing with 'rndc sign
  • Wait till zone has been completely signed (watch rndc signing -list )
  • Plot the signature expirations and see if they are spread out (I have a program that does this, referenced below).

What is the current bug behavior?

  • No jittering of the signature expirations is observed.
  • The expiration dates are all set to exactly the signature validity period in the future.

What is the expected correct behavior?

  • My test used a config of "sig-validity-interval 60 10"
  • The resulting signature expirations should be spread out across the range 10 days to 60 days.
  • (But they all expire at 60 days.)

Relevant configuration files

We discovered this issue on some of our large production zones. I then reproduced the problem with a smaller test.

My test zone uses the following config file snippet:

zone "blah.com" {
        type master;
        update-policy local;
        auto-dnssec maintain;
        sig-validity-interval 60 10;
        file "zones/blah.com/zonefile";
        key-directory "zones/blah.com";
        notify no;
};

The main "options" stanza also has "dnssec-enable yes;" of course. But I think that's now the default.

Relevant logs and/or screenshots

I've attached two files containing plots of the signature expiration times for my test zone which contained 10,000 RRsets. These plots were generated by the following code:

https://github.com/shuque/dnsmisc/blob/master/plot-rrsig-expirations.py

The first plot is the test of the NSEC3 zone, initialized by dynamically updating an NSEC3PARAM record. This shows no jittering. All signatures expire at around 60 days:

blah-com-rrsigs-nsec3param

The second plot is for the same zone, but with no NSEC3, and the signatures are jittered correctly for this:

blah-com-rrsigs-no-nsec3param

One peculiarity worth noting: when we were originally using this feature, it was working even with NSEC3 zones, but we were using a different method to initialize them: we pre-populated the zone file with the NSEC3PARAM record first, then loaded it into BIND and triggered signing. This worked for a while until we ran into another bug where BIND would sometimes generate incomplete NSEC3 chains. Then after discussion with ISC, we learned that this is not a supported way to initialize NSEC3 zones, and that we should switch to the supported method of inserting the NSEC3PARAM record with UPDATE.

Possible fixes

Assignee
Assign to
November 2019 (9.11.13, 9.14.8, 9.15.6)
Milestone
November 2019 (9.11.13, 9.14.8, 9.15.6) (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: isc-projects/bind9#1256