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-boun...@lists.isc.org] On Behalf Of Alan
Clegg
Sent: March-18-19 9:12 PM
To: bind-users@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
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
