RE: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
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
RE: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
Hi Mark.
The changes you recommended worked - once I removed the update-policy local /
allow-update statements, named started up with only a single complaint. I have
not created any DNSSEC keyfiles yet and I suspect that it why I am seeing the
following:
- named creates the following log entry for each of my zones on
restart: 'zone /IN/“internals” (signed): receive_secure_serial:
unchanged'
- signed versions of the zonefiles were created, but they are the same
size as the unsigned zonefiles and do not contain any DNSSEC records
I tried to use dnssec-keymgr with a dnssec-policy-[in|ex]ternals.conf file to
generate the keys. It runs without issue but does not generate any keyfiles.
I am running it like this:
sudo /var/named/sbin/dnssec-keymgr -c
/var/named/etc/dnssec-policy-externals.conf
...and I also tried it like this:
sudo /var/named/sbin/dnssec-keymgr -c
/var/named/etc/dnssec-policy-externals.conf -g /var/named/sbin/dnssec-keygen -s
/var/named/sbin/dnssec-settime
It is no longer complaining about my .conf file (I had some syntax errors
initially) and produces no other output. It completes with exit status of 0.
My .conf file contains the following:
POLICIES
policy {
## Default
algorithm RSASHA256;
## Default (1 year)
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
coverage 606461;
## Default
key-size ksk 2048;
## Changed from 1024
key-size zsk 2048;
## Default (1 hour)
keyttl 3600;
## Default (1 month) (divided yearly number by 12)
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
pre-publish ksk 50538;
## Default (1 month) (divided yearly number by 12)
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
pre-publish zsk 50538;
## Default (1 month) (divided yearly number by 12)
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
post-publish ksk 50538;
## Default (1 month) (divided yearly number by 12)
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
post-publish zsk 50538;
## Changed from default of never to 1 year
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
roll-period ksk 606461;
## Changed from default of 1 year to 3 months
## Note that in the UAT, this timing value has been divided by 52 in
order to accelerate changes
roll-period zsk 151615;
}; ## End of policy
ZONES
## Provide a mapping for zone "" as defined in dns group var
dns_zones_externals
zone "" {
## Include policy from above
policy ;
## Set key directory
directory "/var/named/keys/externals/";
}; ## End of zone ""
... and the zone cfg is repeated once for each additional configured zone.
Am I using the dnssec-keymgr utility improperly? The documentation indicates
that "If a specified zone does not already have keys in place, then keys will
be generated for it according to policy." (p. 219).
Thanks!
Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: March-18-19 9:17 PM
To: LeBlanc, Daniel James
Cc: bind-users@lists.isc.org
Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
> On 19 Mar 2019, at 10:59 am, LeBlanc, Daniel James
> wrote:
>
> Thanks Mark for your quick response.
>
> On page 29 of the Bv9-12-3-P1ARM I had seen the following, which is why I
> thought that I "needed" to have one of those statements:
>
>
> " Using the auto-dnssec option requires the zone to be configured to allow
> dynamic updates, by adding an allow-update or update-policy statement to the
> zone configuration. If this has not been done, the configuration will fail.”
Which applies to master zones w/o "inline-signing yes;”. If I’m remembering
history correctly auto-dnssec
existed well before inline-signing and that description wasn’t updated.
> I was looking to do fully automatic signing using auto-dnssec maintain;. If
> that is not possible I could still live with an rndc-based approach if
> required.
Name will maintain the zone. Switching between NSEC and NSEC3 requires rndc as
you
don’t directly manipulate the zone content with dynamic updates. Rolling the
keys
is done with dnssec-settime and dnssec-keygen or dnssec-keymgr.
> I will try this out in the morning.
>
> Thanks again!
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell
Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
> On 19 Mar 2019, at 10:59 am, LeBlanc, Daniel James
> wrote:
>
> Thanks Mark for your quick response.
>
> On page 29 of the Bv9-12-3-P1ARM I had seen the following, which is why I
> thought that I "needed" to have one of those statements:
>
>
> " Using the auto-dnssec option requires the zone to be configured to allow
> dynamic updates, by adding an allow-update or update-policy statement to the
> zone configuration. If this has not been done, the configuration will fail.”
Which applies to master zones w/o "inline-signing yes;”. If I’m remembering
history correctly auto-dnssec
existed well before inline-signing and that description wasn’t updated.
> I was looking to do fully automatic signing using auto-dnssec maintain;. If
> that is not possible I could still live with an rndc-based approach if
> required.
Name will maintain the zone. Switching between NSEC and NSEC3 requires rndc as
you
don’t directly manipulate the zone content with dynamic updates. Rolling the
keys
is done with dnssec-settime and dnssec-keygen or dnssec-keymgr.
> I will try this out in the morning.
>
> Thanks again!
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: March-18-19 8:40 PM
> To: LeBlanc, Daniel James
> Cc: bind-users@lists.isc.org
> Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
>
> You don’t need update-policy local. In inline-signing mode named maintains
> its own copy
> of the zone with the DNSSEC records in addition to the copy from upstream.
> DNSSEC is
> controlled by rndc.
>
>> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
>> wrote:
>>
>> Hello All.
>>
>> 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…
>>
>> If I include required statements within the zone options BIND complained
>> that update-policy local is not permitted in a zone of type slave (and
>> failed to start):
>>
>>key-directory "keys/externals/{{ zone.zonename }}";
>>inline-signing yes;
>>auto-dnssec maintain;
>>update-policy local;
>>
>> So I switched it out for the allow-update { localhost; };, and BIND
>> complained that allow-update is not permitted in a zone of type slave (and
>> failed to start).
>>
>> So I changed my zone type from slave to master (recall that these BIND
>> instances are intended to be slaved off of the Hidden Masters), and BIND
>> complained that masters statements were not permitted in zones of type
>> master (meaning that updates would not be accepted).
>>
>> Is there a way for me to sign the zones on the slave servers, even though I
>> intend to provision content into those same zones on the proprietary Hidden
>> Masters?
>>
>> Thanks.
>>
>> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>>
>> ___
>> 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
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
--
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: 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
RE: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
Thanks Mark for your quick response.
On page 29 of the Bv9-12-3-P1ARM I had seen the following, which is why I
thought that I "needed" to have one of those statements:
" Using the auto-dnssec option requires the zone to be configured to allow
dynamic updates, by adding an allow-update or update-policy statement to the
zone configuration. If this has not been done, the configuration will fail."
I was looking to do fully automatic signing using auto-dnssec maintain;. If
that is not possible I could still live with an rndc-based approach if required.
I will try this out in the morning.
Thanks again!
Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: March-18-19 8:40 PM
To: LeBlanc, Daniel James
Cc: bind-users@lists.isc.org
Subject: Re: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
You don’t need update-policy local. In inline-signing mode named maintains its
own copy
of the zone with the DNSSEC records in addition to the copy from upstream.
DNSSEC is
controlled by rndc.
> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
> wrote:
>
> Hello All.
>
> 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…
>
> If I include required statements within the zone options BIND complained that
> update-policy local is not permitted in a zone of type slave (and failed to
> start):
>
> key-directory "keys/externals/{{ zone.zonename }}";
> inline-signing yes;
> auto-dnssec maintain;
> update-policy local;
>
> So I switched it out for the allow-update { localhost; };, and BIND
> complained that allow-update is not permitted in a zone of type slave (and
> failed to start).
>
> So I changed my zone type from slave to master (recall that these BIND
> instances are intended to be slaved off of the Hidden Masters), and BIND
> complained that masters statements were not permitted in zones of type master
> (meaning that updates would not be accepted).
>
> Is there a way for me to sign the zones on the slave servers, even though I
> intend to provision content into those same zones on the proprietary Hidden
> Masters?
>
> Thanks.
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> ___
> 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
--
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: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
You don’t need update-policy local. In inline-signing mode named maintains its
own copy
of the zone with the DNSSEC records in addition to the copy from upstream.
DNSSEC is
controlled by rndc.
> On 19 Mar 2019, at 10:33 am, LeBlanc, Daniel James
> wrote:
>
> Hello All.
>
> 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…
>
> If I include required statements within the zone options BIND complained that
> update-policy local is not permitted in a zone of type slave (and failed to
> start):
>
> key-directory "keys/externals/{{ zone.zonename }}";
> inline-signing yes;
> auto-dnssec maintain;
> update-policy local;
>
> So I switched it out for the allow-update { localhost; };, and BIND
> complained that allow-update is not permitted in a zone of type slave (and
> failed to start).
>
> So I changed my zone type from slave to master (recall that these BIND
> instances are intended to be slaved off of the Hidden Masters), and BIND
> complained that masters statements were not permitted in zones of type master
> (meaning that updates would not be accepted).
>
> Is there a way for me to sign the zones on the slave servers, even though I
> intend to provision content into those same zones on the proprietary Hidden
> Masters?
>
> Thanks.
>
> Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
>
> ___
> 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
--
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
ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing
Hello All.
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...
If I include required statements within the zone options BIND complained that
update-policy local is not permitted in a zone of type slave (and failed to
start):
key-directory "keys/externals/{{ zone.zonename }}";
inline-signing yes;
auto-dnssec maintain;
update-policy local;
So I switched it out for the allow-update { localhost; };, and BIND complained
that allow-update is not permitted in a zone of type slave (and failed to
start).
So I changed my zone type from slave to master (recall that these BIND
instances are intended to be slaved off of the Hidden Masters), and BIND
complained that masters statements were not permitted in zones of type master
(meaning that updates would not be accepted).
Is there a way for me to sign the zones on the slave servers, even though I
intend to provision content into those same zones on the proprietary Hidden
Masters?
Thanks.
Daniel J. LeBlanc, P.Eng., MBA, DTME | Senior Network Architect | Bell Canada
___
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
