ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing

[LeBlanc, Daniel James]

Hi Alan.

Thanks for your detailed response.  I am not quite at the point where I have reviewed everything required to roll the keys.  However, you have brought to light the challenge that I will have with rolling the keys properly if I am signing on multiple auth DNS servers simultaneously.  Your proposed solution will work, but the single point of failures that you have described are something that we have worked hard to avoid.  We are currently working on the two site deployment but more are planned.  Our objectives are as follows:

	- every site should be capable of operating completely on its own
	- every instance of a functional unit (i.e. authoritative DNS) should be configured identically in every site
	- deployment and configuration is being automated
	- failover between sites is required

On the authoritative DNS servers, I would like to use the same keyfiles per zone at every site (remember, the updating of the configuration is fully automated).  I will need to generate the keys on only one of the systems and then distribute to the others (this can all be automated).  This will need to happen at specific times each year to ensure that sufficient keyfiles are available to be distributed.  Once the keyfiles are distributed, will dnssec-keymgr ensure that they are published, activated, revoked, retired, deleted according to the dates specified in the keyfiles?  The documentation seems to indicate that it will.  If so, the complexity for me will be to ensure that the generation of new keyfiles happens on schedule, and that the proper alarming is in place if it does not.

Thoughts?

Thanks!

Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada

-----Original Message-----
From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Alan Clegg
Sent: March-18-19 9:12 PM
To: bind-users at lists.isc.org
Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing

On 3/18/19 7:33 PM, LeBlanc, Daniel James wrote:

> I have a pair of ISC BIND 9.12.3-P1 servers that are configured as
> slaves to a pair of Hidden Master servers.  The Hidden Masters are a
> proprietary product and unfortunately when used to sign the zones, the
> SOA records are not populated as expected.  As a result, I was looking
> into signing the zones within ISC BIND instead.  Reviewed the
> literature, came up with a plan and the required configuration changes.
>  However, things are not proceeding as I had hoped.

As Mark noted, the "update-policy local" is not going to work as
expected, but I'd like to expound a bit..

I would recommend, not knowing how you are currently configured nor what
you found on "how to do this", the following:

Modify one of your existing slave servers to act as an in-line signer.
Have your hidden master ONLY zone transfer to this chosen signer.

Configure your zones on the in-line signer as you have already noted.
You now have keying material only on the in-line signing system.
Protect it as you would anything valuable.

Set up any other existing servers as slaves of the in-line signer. In
this way, you will have only one server that needs to keep you DNSKEYs
safe, have keys updated in only one location, and actually do the "heavy
lifting" of signing on that one box.

I realize you say you only have two slaves at this point, but when the
third (or 12th) comes along, this centralization of signing is going to
make your life much easier.  You won't have to worry about key
distribution, keeping everything in sync as far as key rollover, etc.

Caveats:  This will create "single points of failure" that now includes
both your hidden master and the inline-signer.  If the inline-signer
falls over, the other slave(s) will continue to serve the zone data
until either the in-line signer is fixed, or the expire timer in the SOA
comes around and your zones all get deathly ill.   Add extra monitoring
to the "distribution master" so that you know immediately if it has issues.

If you were already doing all of this, carry on!  Highly recommended
solution!  If you are using another method, I'm curious as to your
configuration.

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

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