Skip Menu |
Report information
The Basics
Id: 45281
Status: open
Priority: 50/50
Queue: bind9-public

Bug Information
Version Fixed: (no value)
Version Found: 9.9.8-P3
Versions Affected: (no value)
Versions Planned: 9.9.12, 9.10.7, 9.11.3
Priority: P2 Normal
Severity: S3 Low
CVSS Score: (no value)
CVE ID: (no value)
Component: BIND Server
Area: bug

Created:Wed, 24 May 2017 07:26:30 +0000
Updated:Fri, 07 Jun 2019 17:10:55 +0000
Closed:Not set

This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: rndc sign after a key roll doesn't match covering RRSIG TTLs with RR TTLs properly
Download (untitled) / with headers
text/plain 2.3KiB
The zones are managed using inline signing. In this specific instance, the signed zone has been adopted from another DNS provisioning organisation and the public keys imported into the zone using dnssec-importkey. The old RRSIGs will have been expiring naturally since ownership of the zone was transferred. The next step has been to roll the keys so that the old keys are retired. The keys were removed by use of: $ dnssec-settime -D -1 /path/to/Ksmplezone.+008+99999.key $ rndc sign samplezone Following this, and not consistently (as in, not all RRsets have this problem, and not all zones treated to the same process have encountered the issue), but in some cases, the TTLs of the RRSIGs generated don't match the TTLs on the RRsets that they cover. For example: GJ050EV20BAIGROA12RTHHLJD97AF672.samplezone. 10800 IN RRSIG NSEC3 8 2 10800 20170604232817 20170430232547 5586 samplezone. ia4bp3JpaBYZDOj+gBCwPtA+eOPk6vkWCr+lMFM6rzwnye+ZWgNgJ78v 2HipQRAe/X0pQWqoJKimMC1jRU2sj+JTlu9RDvxOA5ZeP6k65e8YIzKY E1NzVXUJ2e+YgomJiI/v72W0MJdEkyW1nQhe7xZ dFFCzV1FykKlXxoP1 nJT+deFvq6u0wItBWcLsBAphUg9fXhC6hRwNLbg2YasAtBHIT6H/hZqO aQbrriOX0C8FAIckkH5V6v+5aN3QqklMflI/wHbBFOC3ZCBN03AMQkFp bjxY1VLo0vCbvU2LE5PczU5nUbPglLBIIbVI/u5KsflR40J0wwUsEp0v OYUlCg== GJ050EV20BAIGROA12RTHHLJD97AF672.samplezone. 3600 IN NSEC3 1 0 10 497E730B PGES0URI1U8F2U362CLIDVP1QTSEODPS A RRSIG The mismatch self-corrects as the auto-resigning replaces DNSSEC signatures - it's been created by the use of rndc sign against the zone (and only noticed because of the use of a DNSSEC validator tool that is applied against the zone. Technically, it doesn't matter that the TTLs don't match, and it shouldn't make a significant operational difference, but it's thought to be better that they do. The problem doesn't occur if using "rndc loadkeys" instead of "rndc sign" in this situation. "sign" causes the zone to be fully signed right away using all of the active keys in the DNSKEY rrset, whereas "loadkeys" just updates the DNSKEY rrset and lets the zone carry on as scheduled. In this situation the keys being deleted were not being used to sign the zone, so there should be no need to walk the zone re-signing anything; "rndc loadkeys" is sufficient. Conclusion - there's a low grade bug in the "rndc sign" code path that sets the TTL incorrectly when generating signatures.
> Conclusion - there's a low grade bug in the "rndc sign" code path that > sets the TTL incorrectly when generating signatures. A new development on this one - it seems that it's not just 'rndc sign' that does this, but that 'rndc loadkeys' also can (in this instance, it was during the removal of expired keys). The steps were: - remove the post published keys from several zones - use rndc loadkeys to get BIND to load the changed keydata The outcome: RRSIG's original TTL differs from corresponding records' It's understood that this shouldn't cause client DNSSEC-validators any problems.
This is similar to (or may be duplicated by) new report