Bind9.11: dnssec inline signing, cds records and catalog zones

Philippe Maechler pmaechler-ml at glattnet.ch
Fri Dec 21 13:54:24 UTC 2018


regarding my OT question for dnssec-keymgmr:

I found it 😊 

I had to enable the python option (Build with python utilities) when building the port

 

/BR

Philippe

 

 

 

From: bind-users <bind-users-bounces at lists.isc.org> On Behalf Of Philippe Maechler
Sent: Friday, December 21, 2018 2:33 PM
To: bind-users at lists.isc.org
Subject: FW: Bind9.11: dnssec inline signing, cds records and catalog zones

 

Hello bind-users

 

The previous mail was sent from a foreign address and need the approval of a moderator. Therefor I cancelled the submission and resending this mail with the correct address.

 

 

Since a few years I’d like to activate dnssec for our zones but didn’t made the changes, because of the maintenance tasks that are needed (what happens if I’m not around and something goes wrong?)

 

Some background info:

 

There is a small web portal on our master server, where we have all our zones in a database. A script periodically checks if we have some changes and if we have them, the scripts generates:

*	The catalog-zone file
*	The zone file
*	Our named.zones.conf

 

If dnssec is enabled for the zone, the entry in named.zones.conf looks like that:

 

zone "example.ch." { 

        type master; 

        file "/usr/local/etc/namedb/master/example.ch.db";

        masterfile-format text;

        notify yes;

        also-notify { 192.168.x.a; 192.168.x.b; 192.168.x.c; 192.168.x.d;  };

        allow-transfer { xfer; };

 

       # look for dnssec keys here:

        key-directory "/usr/local/etc/namedb/keys/example.ch";

 

        # use inline signing:

        inline-signing yes;

 

        # publish and activate dnssec keys:

        auto-dnssec maintain;

};

 

 

This server is not public. It’s a “hidden master” for our public servers. New zones are “deployed” in the cat-zone. With this way we have most of the stuff automated and don’t have to enable new zones on the slave servers.

 

Back to dnssec

 

I then have to create the keys:

dnssec-keygen -a ECDSAP256SHA256 -b 2048 -3 example.ch           # ZSK

dnssec-keygen -a ECDSAP256SHA256 -b 2048 -3 -fk example.ch       # KSK

 

With this setup, I get the example.ch.db.signed, the .signed.jnl and .jbk files. A simple check shows that the dnssec records are present

named-compilezone -f raw -F text -o example.ch.text example.ch example.ch.db.signed && less example.ch.text

 

I then have to manually insert the NSEC3PARAM, otherwise the zone is “only” signed with NSEC.

rndc signing -nsec3param 1 0 10 0123456789ABCDEF example.ch.

 

Question:

Is there a direct way to set the NSEC3PARAM?

 

Switch, the registry for .ch and .li domains is using/testing CDS records. Can I tell named, to create the CDS Records for me?

 

If not, what would be the right way to insert them?

dig @127.0.0.1 dnskey example.ch | dnssec-dsfromkey -f - example.ch

 

example.ch. IN DS 29530 13 1 2FECA428ABA7C9507909AC6ED37B12233575A143

example.ch. IN DS 29530 13 2 5EF2BD239DF5104B12DD0FC8BE671067C52D378C05D4B81C9AF33A77FD5A5356

 

I then would create these two new records in example.ch:

example.ch. IN CDS 29530 13 1 2FECA428ABA7C9507909AC6ED37B12233575A143

example.ch. IN CDS 29530 13 2 5EF2BD239DF5104B12DD0FC8BE671067C52D378C05D4B81C9AF33A77FD5A5356

 

And every time I create or activate new keys, I have to manually add the CDS records, right?

 

 

 

* The domain used for testing is a .ch domain, but not example.ch

 

 

Maybe someone can help me with this, slightly off topic question:

I’m using FreeBSD 11.2 and bind9.11.5 from the ports dir. ISC announced dnssec-keymgr with bind 9.11, which would make the “maintenance task” doe keys easier. 

Unfortunately I can’t find this tool on my box and there is no other port like bind9-tools. 

Do I have to compile that by hand?

 

 

Tia

Philippe

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20181221/1c44725d/attachment.html>


More information about the bind-users mailing list