DNSSEC / BIND breakage

[Viktor Dukhovni]

On Thu, Oct 01, 2015 at 02:35:08PM +0200, Wolfgang Rosenauer wrote:

> I'm using bind and its
> auto-dnssec maintain;
> inline-signing yes;
> 
> Also I'm not aware that my KSK and ZSK keys have any expiration date but
> today DNSSEC started to fail apparently because my RRSIG signatures are
> said to be expired.

Actually KSKs and ZSKs can have expiration dates, it is best to
not set explicitly until you're just about ready to do key rotation.

-- 
	Viktor.

Zone signing keys live in "keys" directory and must be readable by
"named".  To create the keys:

    # dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -3 -f KSK example.net
    # dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 -3 example.net
    # chown named Kexample.net.+008+*

After generating keys and and updating named.conf, to sign a zone:

    # rndc reconfig
    # rndc loadkeys example.net

To enable NSEC3 records for signed zones:

    # zones="example.net"
    # for d in $zones; do
	salt=$(openssl rand -hex 8 | tr '[a-f]' '[A-F]')
	rndc signing -nsec3param 1 0 10 $salt $d.
      done

Periodic sync and truncation of zone journals:

    # for d in $zones; do rndc sync -clean $d.; done

To examine non-DNSSEC data in signed zones:

    # for d in $zones; do
	named-compilezone -jD -f raw -o - $d $d.signed |
	egrep -v 'IN (NSEC|RRSIG|DNSKEY|TYPE65534)|^;'
      done

To extract DS RRs to push to the registrar:

    # for d in $zones; do
	named-compilezone -jD -f raw -o - $d $d.signed 2>/dev/null |
	    dnssec-dsfromkey -f - $d
      done

To change zone content, since the signed zone is compiled, we need
to BUMP THE SERIAL number in the unsigned source to cause re-signing.

    # d=example.net
    # vi $d
    # rndc reload $d
    # rndc sync -clean $d

At this point one can inspect the re-signed zone:

    # named-compilezone -jD -f raw -o - $d $d.signed

ZSK key rollover notes by Carsten Strotmann:
============================================

The way I use the key dates is to specify the "retirement" and
"deletion" only before the new key is generated, e.g. when the
rollover starts. That way, the rollover can be postponed in time
when needed

Example:

	# cd keys
	# dnssec-settime -p all Kexample.net.+008+50340
	Created: Wed Jan 21 09:32:35 2015
	Publish: Thu Jan 22 09:32:35 2015
	Activate: Sun Jan 25 09:32:35 2015
	Revoke: UNSET
	Inactive: UNSET
	Delete: UNSET

    28 days after activation, the rollover process starts by setting
    the inactivation time and creating the successor key.  The
    inactivation interval for the old key is 10 minutes more than
    2 days, This allows for a bit of time delay between the first
    command and the next:

	# dnssec-settime -I $( printf "+%dmi" $(( 2*24*60+10 )) ) -D +8d Kexample.net.+008+50340
	# dnssec-keygen -r /dev/urandom -i 2d -S Kexample.net.+008+50340.key
        # chown named Kexample.net.+008+*
	# rndc loadkeys example.net

By setting the inactivation time not at the creation of the key,
but when the rollover starts, the process is more robust against
failures of the script/process and the rollover can be postponed
if needed.