Re: Automatic DNSSEC signing workflow

[Mark Andrews]

In message <2274914.OQEsm7p8Dx@dan>, "Daniel A. Ramaley" writes:
> On 2016-07-05 at 15:26:31 Tony Finch wrote:
> > There is a third option:
> > 
> > 3) Maintain zone files with a text editor, and use inline-signing mode
> > to get named to sign them.
> > 
> > For option 3 you don't want an update-policy clause.
> 
> OK, that's actually the behavior that i was trying to achieve. Earlier i 
> tried commenting out the update-policy line and doing some testing and 
> it didn't work. But then i discovered a permissions problem on some of 
> the key files. Once i fixed the key files permissions, Bind started 
> behaving exactly the way i'd like it to!
> 
> Thanks again for the help! I've done enough testing now that i'm 
> reasonably confident Bind is behaving the way we want it to, where we 
> can maintain the zone files with a text editor, but let Bind manage the 
> signing.

If you want to use a editor you can always use contrib/zone-edit.sh
which uses nsupdate to perform the actual updates after editing the
zone contents.  The script transfers the current zone from the
server and strips out the most of the DNSSEC records prior to
editing.  Really large changes need to be done in smaller chucks
but for day to day changes it should be not significantly different
from what is currently being done and you don't have to remember
to update the serial.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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 
Date: Tuesday, July 5, 2016 at 10:48 AM
To: Mathew Eis , "bind-users@lists.isc.org" 

Subject: Re: auto-dnssec maintain and DNSKEY removal

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

[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 
Date: Monday, July 4, 2016 at 8:08 AM
To: Mathew Eis 
Cc: "bind-users@lists.isc.org" 
Subject: Re: auto-dnssec maintain and DNSKEY removal

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

Re: Automatic DNSSEC signing workflow

[Daniel A. Ramaley]

On 2016-07-05 at 15:26:31 Tony Finch wrote:
> There is a third option:
> 
> 3) Maintain zone files with a text editor, and use inline-signing mode
> to get named to sign them.
> 
> For option 3 you don't want an update-policy clause.

OK, that's actually the behavior that i was trying to achieve. Earlier i 
tried commenting out the update-policy line and doing some testing and 
it didn't work. But then i discovered a permissions problem on some of 
the key files. Once i fixed the key files permissions, Bind started 
behaving exactly the way i'd like it to!

Thanks again for the help! I've done enough testing now that i'm 
reasonably confident Bind is behaving the way we want it to, where we 
can maintain the zone files with a text editor, but let Bind manage the 
signing.

__
Daniel A. Ramaley  |  Server Engineer 2
Information Technology Services (ITS) | Drake University

T: +1 (515) 271-4540
F: +1 (515) 271-1938
E: daniel.rama...@drake.edu

___
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: Automatic DNSSEC signing workflow

[Tony Finch]

Daniel A. Ramaley  wrote:
>
> From the responses i received, it seems i completely misunderstood how
> automatic signing is supposed to work. If i'm now understanding
> correctly, there are 2 mutually exclusive ways to do things:
>   1) Maintain zone files with a text editor, and sign them manually.
>   2) Maintain zones with nsupdate, and let Bind sign them.

Option 2 is best when you have an update-policy clause. There is no need
for inline-signing in this case.

There is a third option:

3) Maintain zone files with a text editor, and use inline-signing mode to
   get named to sign them.

For option 3 you don't want an update-policy clause.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Dogger: Northwesterly 4 or 5, occasionally 6 in east. Slight or 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: Automatic DNSSEC signing workflow

[Daniel A. Ramaley]

On 2016-07-04 at 15:44:32 Tony Finch  wrote:
> In most cases it is best to either use `nsupdate` exclusively, or
> directly edit the master file, but not a mixture of the two. If you
> are using `nsupdate` then there is no need for inline-signing.

>From the responses i received, it seems i completely misunderstood how 
automatic signing is supposed to work. If i'm now understanding 
correctly, there are 2 mutually exclusive ways to do things:
  1) Maintain zone files with a text editor, and sign them manually.
  2) Maintain zones with nsupdate, and let Bind sign them.

It seems i was mixing the two and not getting the results i expected. 
I'll talk it over with our network administrators (they do most of our 
DNS updates) and see which way they'd prefer to maintain zones, and then 
provide appropriate instructions.

Thanks everyone for clearing up my confusion!

P.S.: Cool e-mail address. I first heard of d...@dotat.at some years 
ago when a friend found out about it randomly. I never expected to 
communicate with the owner of that address though!

__
Daniel A. Ramaley  |  Server Engineer 2
Information Technology Services (ITS) | Drake University

T: +1 (515) 271-4540
F: +1 (515) 271-1938
E: daniel.rama...@drake.edu

___
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

Reply to digests [was: RE: bind-users Digest, Vol 1727, Issue 1]

[Chris Thompson]

On Jul 4 2016, G.W. Haywood wrote:


Hi there,

On Mon, 4 Jul 2016, Amit Kumar Gupta wrote:


[An entire digest message, which I've snipped]


It would be extremely helpful to those of us on the digest list, and
generally more polite, if you would NOT include in your posts to the
list, simply in order to save yourself the time and effort of typing
the list's address and thinking of a subject line, a complete digest
message, two and a half years old and apparently selected at random.


I have long thought that mailing lists should be configured to reject
messages with a Subject of "Re: [the subject format for the list's
digest messages]". Maybe a scan of the message content for a copy of
the digest prologue would be a good idea as well. 


--
Chris Thompson
Email: c...@cam.ac.uk


___
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