Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

inactivating and deleting DNSSEC keys

562 views
Skip to first unread message

David Newman

unread,
Oct 8, 2013, 6:42:37 PM10/8/13
to bind-users
bind 9.9.4

How to troubleshoot issues when keys are supposed to be invalidated or
deleted on specific dates, but aren't?

In this case, a KSK was supposed to be inactivated on 29 September 2013
and deleted on 9 October 2013.

>From the .key file:

; This is a key-signing key, keyid 56989, for networktest.com.
; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)

Problem is, dig says the key is still active, and will be until 29
October 2013:

$ dig networktest.com @localhost +multi rrsig | grep 56989

20131029191450 20130929181450 56989 networktest.com.

named.conf has this:

options {
..
// DNSSEC stuff
managed-keys-directory "managed-keys";
dnssec-enable yes;
dnssec-validation auto;
}

..

zone "networktest.com" {
type master;
..
key-directory "managed-keys/networktest.com";
inline-signing yes;
auto-dnssec maintain;
};

$ ls -l managed-keys/networktest.com/ | grep 56989
-rw-r----- 1 bind bind 719 Jul 31 13:15 Knetworktest.com.+008+56989.key
-rw------- 1 bind bind 1824 Jul 31 13:15
Knetworktest.com.+008+56989.private

I don't understand the disconnect between the configured inactive/delete
times and the ones returned by dig, and presume this is because I've
misconfigured something.

Thanks in advance for troubleshooting clues.

dn

Alan Clegg

unread,
Oct 8, 2013, 6:51:11 PM10/8/13
to David Newman, bind-users

On Oct 8, 2013, at 6:42 PM, David Newman <dne...@networktest.com> wrote:

> bind 9.9.4
>
> How to troubleshoot issues when keys are supposed to be invalidated or
> deleted on specific dates, but aren't?
>
> In this case, a KSK was supposed to be inactivated on 29 September 2013
> and deleted on 9 October 2013.
>
> From the .key file:
>
> ; This is a key-signing key, keyid 56989, for networktest.com.
> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
>
> Problem is, dig says the key is still active, and will be until 29
> October 2013:
>
> $ dig networktest.com @localhost +multi rrsig | grep 56989
>
> 20131029191450 20130929181450 56989 networktest.com.

You don't provide all of the record. It's an RRSIG that is still within it's lifetime.

Do a dig for "DNSKEY" retype at the zone name and see what you get back.

AlanC
--
Alan Clegg | +1-919-355-8851 | al...@clegg.com

signature.asc

Alan Clegg

unread,
Oct 8, 2013, 6:59:47 PM10/8/13
to bind-users List
That was "type" not "retype".

Anyway, this brings up a request that I've made that all RRSIG records be removed if the associated DNSKEYs are removed, but at this point, it's not the default. This taken from "man dnssec-signzone":

-R
Remove signatures from keys that no longer exist.

Normally, when a previously-signed zone is passed as input to the
signer, and a DNSKEY record has been removed and replaced with a
new one, signatures from the old key that are still within their
validity period are retained. This allows the zone to continue to
validate with cached copies of the old DNSKEY RRset. The -R forces
dnssec-signzone to remove all orphaned signatures.

I believe that this should be the default behavior (otherwise, we get double signatures when rolling ZSKs)..

The point of doing all of the timing calculation surrounding key rollover is to solve the problem of those cached keys, I don't think that dnssec-signzone (or the automated signing) is doing anyone a favor.

Or there needs to be a zone (and global) specific option that allows the same "-R" behavior during automated rollovers.
signature.asc

David Newman

unread,
Oct 8, 2013, 7:01:08 PM10/8/13
to bind-users
On 10/8/13 3:51 PM, Alan Clegg wrote:
>
> On Oct 8, 2013, at 6:42 PM, David Newman <dne...@networktest.com>
> wrote:
>
>> bind 9.9.4
>>
>> How to troubleshoot issues when keys are supposed to be
>> invalidated or deleted on specific dates, but aren't?
>>
>> In this case, a KSK was supposed to be inactivated on 29
>> September 2013 and deleted on 9 October 2013.
>>
>> From the .key file:
>>
>> ; This is a key-signing key, keyid 56989, for networktest.com. ;
>> Created: 20130723214837 (Tue Jul 23 14:48:37 2013) ; Publish:
>> 20130723214837 (Tue Jul 23 14:48:37 2013) ; Activate:
>> 20130723214837 (Tue Jul 23 14:48:37 2013) ; Inactive:
>> 20130929201510 (Sun Sep 29 13:15:10 2013) ; Delete:
>> 20131009201510 (Wed Oct 9 13:15:10 2013)
>>
>> Problem is, dig says the key is still active, and will be until
>> 29 October 2013:
>>
>> $ dig networktest.com @localhost +multi rrsig | grep 56989
>> 20131029191450 20130929181450 56989 networktest.com.
>
> You don't provide all of the record. It's an RRSIG that is still
> within it's lifetime.
>
> Do a dig for "DNSKEY" retype at the zone name and see what you
> get back.

I think this is what you're asking for, but if not please let me know.
Thanks.

dn

$ dig networktest.com @localhost +multi dnskey

; <<>> DiG 9.9.4 <<>> networktest.com @localhost +multi dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11568
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;networktest.com. IN DNSKEY

;; ANSWER SECTION:
networktest.com. 3600 IN DNSKEY 256 3 8 (
AwEAAc/YdGPWOi57E4yj6bYw55o9XXYP2V8xNhRFBtQM
6iGLrf+OHzIpA2ffPhL8CHOZxkH6nIKNDzQ9sWnih1O4
BDSI062F8AextdeA2V0cLin43y3YDL0LK8SFaNMPKdwR
hAD3KIXtbvZRFBU1iUEUoRy6ZpO8K0HRSyQgYa5SdqP5
) ; ZSK; alg = RSASHA256; key id = 16788
networktest.com. 3600 IN DNSKEY 257 3 8 (
AwEAAdAmmvkvbIIRoq48aqHToIIcGKImBoKdqUyslOyM
rRH5mxN7o0wc50ib2g6E+EtBWCn3UqrqpGcru1ZHkDoJ
eCf2JbSKViOJPRWgAx1JfVFwO6eL4lDcMGb6OF0OxPCc
9OMkUo6B/76fORJgelbpqKscHAYCo92npR+XpZMoj/Gj
S3sDn8k62eIXkbAFOXQuuGFVfQ0chKSv0QctlcnsTHkF
NRmjwVjN5xYPy0kn0bXVCC8Iiah2RqQAdV4jij2c4iM7
STwlnKYBWslQZGWi8LQgjLgUNOvh0dfWdLCYiQR7WwPf
W5Y2RxgvZ3SmG1+ntX5ps+VU7jKzXnDiPWwKp9M=
) ; KSK; alg = RSASHA256; key id = 56989
networktest.com. 3600 IN DNSKEY 256 3 8 (
AwEAAdPqBf8AF3+QQAP2olQA7vCDieElo65jyWdphIuI
T2Awiwd07a83gXgL9Ezp16b8miO1eOSBOUB+0fmBSI6h
IWCyFNAuh2+P5eCCD+gJq/u2y+ItnyaKZNEFjXF8YJWl
NoLtmf48xJv9QyepbZ4hLqBlIMf//NdNc8lDyXc/iRRV
) ; ZSK; alg = RSASHA256; key id = 30795
networktest.com. 3600 IN DNSKEY 257 3 8 (
AwEAAceMN3Aad/ups4QFO2JmO7cww1kx5DBQwbouQ/iC
H5M+zAfo7XddkJZkVp5A9ZKhSqf982r0En3i1lQrNESE
1ZlWPnDwW8ygBySBORkmNPqLRZG28sBaut2B6n31laWi
1mj1m6U9NNrAiQG2M19IRlaTCcO6Ud7usMyhPogKcE/3
5TjuoMv5nzI/hirzOWhOi4F9gRe8UlsVk8q1gWoWDlL5
oGAIT3VguW3Ifaa9Ywy2BWTy0qSJ6IlMuLtqT+GbJrc+
qvG9/symJYbcwAKz2Ai0Yuiwhmi6E587wsLV/HZkryMR
3GMU/6Nt0H4dyhlwCaK4y9StedVmJwHIwI0HSDE=
) ; KSK; alg = RSASHA256; key id = 20362

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Oct 08 15:58:15 PDT 2013
;; MSG SIZE rcvd: 892



>
> AlanC
>

Mark Andrews

unread,
Oct 8, 2013, 8:54:33 PM10/8/13
to David Newman, bind-users

In message <52548A5D...@networktest.com>, David Newman writes:
> bind 9.9.4
>
> How to troubleshoot issues when keys are supposed to be invalidated or
> deleted on specific dates, but aren't?
>
> In this case, a KSK was supposed to be inactivated on 29 September 2013
> and deleted on 9 October 2013.
>
> >From the .key file:
>
> ; This is a key-signing key, keyid 56989, for networktest.com.
> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
>
> Problem is, dig says the key is still active, and will be until 29
> October 2013:

Named stopped SIGNING with this record on October 29.

Inception (20130929181450) is over a hour (clock skew allowance)
before the Inactivation (20130929201510) time.

The RRSIG will be replaced when the record is due to be re-signed
which is based on the sig-validity-interval.

I would be extending the deletion date to 30 days (sig-validity-interval)
after the inactivation date.

Mark

> $ dig networktest.com @localhost +multi rrsig | grep 56989
>
> 20131029191450 20130929181450 56989 networktest.com.
>
> named.conf has this:
>
> options {
> ..
> // DNSSEC stuff
> managed-keys-directory "managed-keys";
> dnssec-enable yes;
> dnssec-validation auto;
> }
>
> ..
>
> zone "networktest.com" {
> type master;
> ..
> key-directory "managed-keys/networktest.com";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
> $ ls -l managed-keys/networktest.com/ | grep 56989
> -rw-r----- 1 bind bind 719 Jul 31 13:15 Knetworktest.com.+008+56989.key
> -rw------- 1 bind bind 1824 Jul 31 13:15
> Knetworktest.com.+008+56989.private
>
> I don't understand the disconnect between the configured inactive/delete
> times and the ones returned by dig, and presume this is because I've
> misconfigured something.
>
> Thanks in advance for troubleshooting clues.
>
> dn
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

David Newman

unread,
Oct 9, 2013, 1:22:05 PM10/9/13
to bind-users


On 10/8/13 5:54 PM, Mark Andrews wrote:
> In message <52548A5D...@networktest.com>, David Newman writes:
>> bind 9.9.4
>>
>> How to troubleshoot issues when keys are supposed to be invalidated or
>> deleted on specific dates, but aren't?
>>
>> In this case, a KSK was supposed to be inactivated on 29 September 2013
>> and deleted on 9 October 2013.
>>
>> >From the .key file:
>>
>> ; This is a key-signing key, keyid 56989, for networktest.com.
>> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
>> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
>> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
>>
>> Problem is, dig says the key is still active, and will be until 29
>> October 2013:
>
> Named stopped SIGNING with this record on October 29.

Since this is in the future, I think you mean "will stop signing"?

> Inception (20130929181450) is over a hour (clock skew allowance)
> before the Inactivation (20130929201510) time.

OK, do I understand correctly that because the RRSIG got created just
before the inactivate date, it will live on for sig-validity-interval
(30 days in this case), regardless of the key's deletion date?

>
> The RRSIG will be replaced when the record is due to be re-signed
> which is based on the sig-validity-interval.
>
> I would be extending the deletion date to 30 days (sig-validity-interval)
> after the inactivation date.

Right, understood.

In UTC terms, we've already passed the key's deletion date. Can I
retroactively extend the key's deletion date?

Thanks

dn

Mark Andrews

unread,
Oct 9, 2013, 4:24:47 PM10/9/13
to David Newman, bind-users

In message <525590BD...@networktest.com>, David Newman writes:
>
>
> On 10/8/13 5:54 PM, Mark Andrews wrote:
> > In message <52548A5D...@networktest.com>, David Newman writes:
> >> bind 9.9.4
> >>
> >> How to troubleshoot issues when keys are supposed to be invalidated or
> >> deleted on specific dates, but aren't?
> >>
> >> In this case, a KSK was supposed to be inactivated on 29 September 2013
> >> and deleted on 9 October 2013.
> >>
> >> >From the .key file:
> >>
> >> ; This is a key-signing key, keyid 56989, for networktest.com.
> >> ; Created: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Publish: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Activate: 20130723214837 (Tue Jul 23 14:48:37 2013)
> >> ; Inactive: 20130929201510 (Sun Sep 29 13:15:10 2013)
> >> ; Delete: 20131009201510 (Wed Oct 9 13:15:10 2013)
> >>
> >> Problem is, dig says the key is still active, and will be until 29
> >> October 2013:
> >
> > Named stopped SIGNING with this record on October 29.
>
> Since this is in the future, I think you mean "will stop signing"?

Actually it was September 29 so it has now passed.

> > Inception (20130929181450) is over a hour (clock skew allowance)
> > before the Inactivation (20130929201510) time.
>
> OK, do I understand correctly that because the RRSIG got created just
> before the inactivate date, it will live on for sig-validity-interval
> (30 days in this case), regardless of the key's deletion date?

Yes.

> > The RRSIG will be replaced when the record is due to be re-signed
> > which is based on the sig-validity-interval.
> >
> > I would be extending the deletion date to 30 days (sig-validity-interval)
> > after the inactivation date.
>
> Right, understood.
>
> In UTC terms, we've already passed the key's deletion date. Can I
> retroactively extend the key's deletion date?

Yes. The files are not removed. You will need to tell named to re-read
the .private file using "rndc signzone" after setting the time the deletion
time.

David Newman

unread,
Oct 9, 2013, 4:45:28 PM10/9/13
to bind-users
On 10/9/13 1:24 PM, Mark Andrews wrote:

>> In UTC terms, we've already passed the key's deletion date. Can I
>> retroactively extend the key's deletion date?
>
> Yes. The files are not removed. You will need to tell named to re-read
> the .private file using "rndc signzone" after setting the time the deletion
> time.

Thanks, Mark. The signzone command didn't work, but "rndc sign <zone>"
worked fine.

dn

0 new messages