[ISC-support #11491] : rndc sign after a key roll doesn't match covering RRSIG TTLs with RR TTLs proper
From BUGS RT #45281
Found in version 9.9.8-P3
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.
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.