Am 01.10.2015 um 14:35 schrieb Wolfgang Rosenauer:

Hi,

one of my DNSSEC/DANE secured domains started breaking as of today and I do not fully understand why. Probably bright people here can point me to the correct resolution?

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 my first idea is that the automatic maintenance in bind failed for some reason. So I deleted the journal and signed zone files and started over by signing the zone from scratch. This at least improved the situation a little bit according to http://dnsviz.net/d/rosenauer.org/dnssec/

But still it seems to be broken and I'm lost currently to understand what is wrong.

Thanks for any pointers, Wolfgang

there are 2 nameservers known: yaina.de. and ns.an-netz.de. according to the soa, yaina.de seem to be a secondary. I guess the zonetransfer from primary to secondary did not happen because the zone serial is still the same. compare "dig @yaina.de. rosenauer.org. ns +dnssec" with "dig @ns.an-netz.de.rosenauer.org. ns +dnssec" the primary have more and newer RRSIGs. -> everytime a resign happen the serial number must be changed. Andreas -- A. Schulze DATEV eG

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.