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 <zonename>/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 <redacted1> {
## 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 <redacted1>
#### ZONES
## Provide a mapping for zone "<redacted2>" as defined in dns group var
dns_zones_externals
zone "<redacted2>" {
## Include policy from above
policy <redacted1>;
## Set key directory
directory "/var/named/keys/externals/<redacted2>";
}; ## End of zone "<redacted2>"
... 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
> <daniel.lebl...@bellaliant.ca> 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
>> <daniel.lebl...@bellaliant.ca> 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
