ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing

Tue Mar 19 13:57:31 UTC 2019

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:marka at isc.org] 
Sent: March-18-19 9:17 PM
To: LeBlanc, Daniel James
Cc: bind-users at 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.leblanc at 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:marka at isc.org] 
> Sent: March-18-19 8:40 PM
> To: LeBlanc, Daniel James
> Cc: bind-users at 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.leblanc at 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 at 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: marka at isc.org
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org