Re: auto-dnssec maintain and DNSKEY removal

[Mathew Ian Eis]

>I'm not sure how what you are asking for is different from the default.

Indeed, that’s what I get for reading an outdated version of the documentation! 
(which didn’t mention the second field) Looks like it does everything I want…

Thanks again,

-Mathew Eis

-Original Message-
From: Tony Finch <d...@dotat.at>
Date: Thursday, July 14, 2016 at 3:17 AM
To: Mathew Eis <mathew@nau.edu>
Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org>
Subject: Re: auto-dnssec maintain and DNSKEY removal

Mathew Ian Eis <mathew@nau.edu> wrote:
>
> sig-validity-interval seems to only affect the expiration date of newly
> created signatures, and of course signatures are only rolling over to
> new keys as they expire.
>
> I am wondering if I can ask bind to set the expiration for, say 30 days
> out, but when a new key is published, publish all signatures with the
> new key sooner, say, a week before the previous ones expire.

I'm not sure how what you are asking for is different from the default.

Here's what the ARM says (slightly edited for clarity):

: sig-validity-interval specifies the number of days into the future when
: automatically generated DNSSEC signatures will expire. There is an
: optional second field which specifies how long before expiry that the
: signatures will be regenerated. The second field is specified in days if
: the base interval is greater than 7 days otherwise it is specified in
: hours. If not specified, the signatures will be regenerated at 1/4 of
: base interval. The default base interval is 30 days giving a re-signing
: interval of 7 1/2 days.

So typically you would use dnssec-settime to retire the old key and
activate the new key at the same time (so you don't have multiple RRSIGs
per RRset). After this time it will take 22.5 days to replace all the
signatures, so the old signatures will all be gone 7.5 days before the
last one expires.

I've set my servers for faster RRSIG turnover, sig-validity-interval 10 8,
so all signatures are replaced every 2 days, and the 8 day grace period is
a bit longer than the 7 day SOA expire time.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Northwesterly 5 to 7, perhaps gale 8 later. Moderate or rough.
Showers. Good.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Tony Finch]

Mathew Ian Eis  wrote:
>
> sig-validity-interval seems to only affect the expiration date of newly
> created signatures, and of course signatures are only rolling over to
> new keys as they expire.
>
> I am wondering if I can ask bind to set the expiration for, say 30 days
> out, but when a new key is published, publish all signatures with the
> new key sooner, say, a week before the previous ones expire.

I'm not sure how what you are asking for is different from the default.

Here's what the ARM says (slightly edited for clarity):

: sig-validity-interval specifies the number of days into the future when
: automatically generated DNSSEC signatures will expire. There is an
: optional second field which specifies how long before expiry that the
: signatures will be regenerated. The second field is specified in days if
: the base interval is greater than 7 days otherwise it is specified in
: hours. If not specified, the signatures will be regenerated at 1/4 of
: base interval. The default base interval is 30 days giving a re-signing
: interval of 7 1/2 days.

So typically you would use dnssec-settime to retire the old key and
activate the new key at the same time (so you don't have multiple RRSIGs
per RRset). After this time it will take 22.5 days to replace all the
signatures, so the old signatures will all be gone 7.5 days before the
last one expires.

I've set my servers for faster RRSIG turnover, sig-validity-interval 10 8,
so all signatures are replaced every 2 days, and the 8 day grace period is
a bit longer than the 7 day SOA expire time.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Northwesterly 5 to 7, perhaps gale 8 later. Moderate or rough.
Showers. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Mathew Ian Eis]

One last question (I hope):

sig-validity-interval seems to only affect the expiration date of newly created 
signatures, and of course signatures are only rolling over to new keys as they 
expire.

I am wondering if I can ask bind to set the expiration for, say 30 days out, 
but when a new key is published, publish all signatures with the new key 
sooner, say, a week before the previous ones expire.

One option would be to use rndc sign [zone] to forcibly re-sign all records 
with all published keys, but of course that would upset any jitter… Are there 
any other approaches?

Thanks again,

Mathew Eis

-Original Message-
From: Tony Finch <d...@dotat.at>
Date: Wednesday, July 6, 2016 at 2:48 AM
To: Mathew Eis <mathew@nau.edu>
Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org>
Subject: Re: auto-dnssec maintain and DNSKEY removal

Mathew Ian Eis <mathew@nau.edu> wrote:
>
> Does all of that sound right?

I believe so, yes.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight, Portland, Plymouth, North Biscay: Northwesterly,
backing southwesterly, 3 or 4, becoming variable for a time. Smooth or slight,
occasionally moderate in Humber and Biscay. Fair. Good.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Tony Finch]

Mathew Ian Eis  wrote:
>
> Does all of that sound right?

I believe so, yes.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight, Portland, Plymouth, North Biscay: Northwesterly,
backing southwesterly, 3 or 4, becoming variable for a time. Smooth or slight,
occasionally moderate in Humber and Biscay. Fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Mathew Ian Eis]

Thanks for the clarification.

In terms of config options, I assume we are talking about the following:
dnssec-loadkeys-interval (with a default of 60 minutes)
sig-validity-interval (with a default of 30 days)

So…

A new key should be published for at least [sig-validity-interval] before 
deletion of the old key to allow for sufficient time for the signatures to roll 
over to the newer key. Presumably anything less may cause a potential extended 
use of the old key (beyond expiration and possibly even deletion times).

As far as removing the underlying key file, it sounds like the best practice 
would be to wait until the key has been removed from DNS (after deletion time, 
but possibly later if other configs are not sane) - plus waiting an additional 
dnssec-loadkeys-interval before finally removing the underlying file.

With both of the above in place, auto-dnssec maintain should do its thing and 
not hang onto zombie keys anymore.

Does all of that sound right?

Thanks again,

-Mathew Eis

From: Tony Finch <d...@dotat.at>
Date: Tuesday, July 5, 2016 at 10:48 AM
To: Mathew Eis <mathew@nau.edu>, "bind-users@lists.isc.org" 
<bind-users@lists.isc.org>
Subject: Re: auto-dnssec maintain and DNSKEY removal

Mathew Ian Eis <mathew@nau.edu> wrote:
>
> > Are you allowing enough time for named to go through a zone key maintenance 
> > cycle? (which is hourly if I remember correctly)
>
> I’m not sure, it sounds like perhaps not always? You’ve mentioned a “zone
> key maintenance cycle” of an hour, and the docs also casually mention
> that “by default, this [key] rollover completes in 30 days” [1].

These are two separate things.

The zone key maintenance timer controls when named re-examines a zone's keys 
(checks for changes to the files, loads new keys, etc.) I haven't checked this 
myself in detail, but named can get confused and upset if a key file disappears 
while named thinks the key is still in use, so I suspect it might go wrong if 
the file is deleted after the key deletion time but before the zone key timer 
triggers.

The rollover time is related to the signature lifetime - you have to stop 
signing with a key, allow a month for the signatures to be replaced, then 
delete the key, and you specify all this with dnssec-settimes, and check it is 
sane with dnssec-coverage. (Which I am sure you know but I wanted to avoid 
confusion.)

> How long after deletion time is it safe to actually remove the underlying
> key files, if it isn’t the deletion time itself?

You should probably augment your key file deletion script to verify that the 
key has in fact gone from the zone - if you add suitable warning diagnostics it 
will probably reveal what is actually going wrong, more reliably than my 
guesses!

Tony.
--
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Tony Finch]

Mathew Ian Eis  wrote:
>
> > Are you allowing enough time for named to go through a zone key
> > maintenance cycle? (which is hourly if I remember correctly)
>
> I’m not sure, it sounds like perhaps not always? You’ve
> mentioned a “zone
> key maintenance cycle” of an hour, and the docs also casually mention
> that “by default, this [key] rollover completes in 30 days” [1].
 
These are two separate things.
 
The zone key maintenance timer controls when named re-examines a zone's
keys (checks for changes to the files, loads new keys, etc.) I haven't
checked this myself in detail, but named can get confused and upset if a
key file disappears while named thinks the key is still in use, so I
suspect it might go wrong if the file is deleted after the key deletion
time but before the zone key timer triggers.
 
The rollover time is related to the signature lifetime - you have to
stop signing with a key, allow a month for the signatures to be
replaced, then delete the key, and you specify all this with dnssec-
settimes, and check it is sane with dnssec-coverage. (Which I am sure
you know but I wanted to avoid confusion.)
 
> How long after deletion time is it safe to actually remove the
> underlying
> key files, if it isn’t the deletion time itself?
 
You should probably augment your key file deletion script to verify that
the key has in fact gone from the zone - if you add suitable warning
diagnostics it will probably reveal what is actually going wrong, more
reliably than my guesses!
 
Tony.
--
f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode
 
 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Mathew Ian Eis]

> How promptly are you deleting the key files?

Any time >= deletion time, varying… we think this could explain why only some 
of the DNSKEYs are becoming zombies, but not all.

> Are you allowing enough time for named to go through a zone key maintenance 
> cycle? (which is hourly if I remember correctly)

I’m not sure, it sounds like perhaps not always? You’ve mentioned a “zone key 
maintenance cycle” of an hour, and the docs also casually mention that “by 
default, this [key] rollover completes in 30 days” [1]. 

How long after deletion time is it safe to actually remove the underlying key 
files, if it isn’t the deletion time itself?

-Mathew Eis

[1] ftp://ftp.isc.org/isc/bind/9.8.0-P4/doc/arm/Bv9ARM.ch04.html

-Original Message-
From: Tony Finch <d...@dotat.at>
Date: Monday, July 4, 2016 at 8:08 AM
To: Mathew Eis <mathew@nau.edu>
Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org>
Subject: Re: auto-dnssec maintain and DNSKEY removal

Mathew Ian Eis <mathew@nau.edu> wrote:
>
> We think that in some cases, named may be choosing to use a key past the
> removal date (as in [2]), while our file maintenance process removes the
> keys as per their deletion date – after which named no longer has the
> necessary metadata to determine whether or not to remove the DNSKEY from
> the zone.

How promptly are you deleting the key files? Are you allowing enough time
for named to go through a zone key maintenance cycle? (which is hourly if
I remember correctly)

> Lastly, so long as a zone is properly signed with a different key, are
> there any concerns with manually removing the zombie DNSKEY records via
> an update even while auto-dnssec maintain is enabled?

I believe that should work.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
North Rockall: Westerly or northwesterly 3 or 4, increasing 5 at times.
Moderate. Showers. Good.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain and DNSKEY removal

[Tony Finch]

Mathew Ian Eis  wrote:
>
> We think that in some cases, named may be choosing to use a key past the
> removal date (as in [2]), while our file maintenance process removes the
> keys as per their deletion date – after which named no longer has the
> necessary metadata to determine whether or not to remove the DNSKEY from
> the zone.

How promptly are you deleting the key files? Are you allowing enough time
for named to go through a zone key maintenance cycle? (which is hourly if
I remember correctly)

> Lastly, so long as a zone is properly signed with a different key, are
> there any concerns with manually removing the zombie DNSKEY records via
> an update even while auto-dnssec maintain is enabled?

I believe that should work.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
North Rockall: Westerly or northwesterly 3 or 4, increasing 5 at times.
Moderate. Showers. Good.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

auto-dnssec maintain and DNSKEY removal

[Mathew Ian Eis]

Hi BIND,

The documentation for auto-dnssec maintain suggests that named will remove 
DNSKEYs from zones when the deletion time marked in the metadata occurs [1]. 
Unfortunately, it seems this is not always the case.

We are currently trying to diagnose the source of residual DNSKEYs in our zones 
- despite our use of auto-dnssec maintain.

We think that in some cases, named may be choosing to use a key past the 
removal date (as in [2]), while our file maintenance process removes the keys 
as per their deletion date – after which named no longer has the necessary 
metadata to determine whether or not to remove the DNSKEY from the zone.

Does this sound possible? Are there any other circumstances that would lead 
named to not removed a DNSKEY in a timely manner?

Lastly, so long as a zone is properly signed with a different key, are there 
any concerns with manually removing the zombie DNSKEY records via an update 
even while auto-dnssec maintain is enabled?

Thanks in advance,

Mathew Eis
Northern Arizona University
Information Technology Services

[1] ftp://ftp.isc.org/isc/bind/9.8.0-P4/doc/arm/Bv9ARM.ch04.html
auto-dnssec maintain … will also automatically adjust the zone's DNSKEY records 
on schedule according to the keys' timing metadata.

[2] 
https://kb.isc.org/article/AA-00822/0/Automatic-DNSSEC-Zone-Signing-Key-rollover-explained.html
It may also be necessary for some keys to be used past their end date.  An 
example of this would be if a key is added but no following key is provided.  
Rather than break the zone, the older key may continue to be used, with 
sufficient notification in the log files to indicate this is happening.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users