DNSSECReport.com

It is possible to set the date the signed zonefile will expire to the recursive validators
caching your domain. DNSSEC requires periodic resigning of the zone file and it's
propagation to the slave servers one TTL prior to the expiration date to protect
the domain.

The default zone signing expiration is 30 days. You may want to give yourself
more time to resign the zone file by bumping this time up to 90 days from the
date of signing.

It is not recommended to go beyond 90 days since an attacker could get a
copy of the signed zone file in transit and create a mirrored site. This limits
the amount of time an attacker needs to crack the key and recreate the
name service.

Use the following command to change the zone signing expiration from the default
of 30 days to 90 days (7,776,000 seconds):

NSEC3 (better security)

dnssec-signzone -a -H 10 -3 bbbb -k domain.net.+007+56487 \
-o domain.net -e +7776000 domain.net Kdomain.net.+007+62648

dnssec-signzone -a -k domain.net.+005+56487 \
-o domain.net -e +7776000 domain.net Kdomain.net.+005+62648

There are two accepted key types you can choose from to sign a zone using
DNSSEC. They are:

dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 2048 -n ZONE domain.net
dnssec-keygen -a NSEC3RSASHA1 -b 2048 -e -n ZONE domain.net
dnssec-keygen -a NSEC3RSASHA1 -b 2048 -e -n ZONE domain.net

dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE domain.net
dnssec-keygen -a RSASHA1 -b 2048 -e -n ZONE domain.net
dnssec-keygen -a RSASHA1 -b 2048 -e -n ZONE domain.net

The Key Signing Key (KSK) is the trust anchor for the domain. This key
is not used to sign the domain contents and can be changed independently of
the Zone Signing Keys (ZSKs). A KSK should be generated with the RSASHA1
or NSEC3RSASHA1 algorthm and 2048 bits in length. KSKs should be
changed every 24 months to new keys. It is this change process
we call a 'rollover'.

The NIST recommended KSK rolling procedure is to pre-publish
the KSK a few days prior to the roll to get the new key distributed to
the validator community. The validators get this key from the parent domain,
so you must follow these steps to successfully prepublish a KSK using Bind:

1. Generate KSK
2. Add an $include statement in your named.conf file
3. Restart the named service
4. Upload the keyset to the parent to publish the DS Resource Record
5. After the DS record has been distributed, resign the zone with the new
KSK using the -k option.
6. Restart the named service.

After this has completed successfully, you may remove the old KSK
$include statement from your named.conf file.

The Zone Signing Key (ZSK) is one or more keys used to sign the
contents of the zone. These keys are separate from the Key Signing
Key (KSK) and can be changed independently. A ZSK should be RSASHA1
or NSEC3RSASHA1 algorthm and 2048 bits in length. ZSKs should be
changed every 30 to 90 days to new keys. It is this change process
we call a 'rollover'.

The NIST recommended ZSK rolling procedure is to always pre-publish
the ZSK in the zone to minimize the labor required to maintain secure
DNS zones. The pre-published ZSK will become the ZSK and already
be distributed to the validator community. The validators get this key
from your zone directly so the parent zone does not need to be
notified when the ZSK keys change.

We recommend these steps to successfully prepublish a ZSK using Bind:

1. Generate ZSK
2. Add an $include statement in your named.conf file for this key
3. Restart the named service
4. After the ZSK record has been distributed to the validators, resign
the zone passing this key as the ZSK.
5. Restart the named service.

After this has completed successfully, you may remove the old ZSK
$include statement from your named.conf file.

Glossary of Terms:

Digital Signer (DS) Resource Record - a SHA256 hash of a public
Key Signing Key

domain - a unique name that is resolved by a DNS query

dnssec-signzone - the isc.org Bind command line tool that signs domain files

dsset-'zone' file - A file of SHA1 and SHA256 key hashes of KSKs to be signed
by the parent domain and create a trust anchor for recursive, validating DNS servers

hash count - The number of hashes performed on a domain when resolving a DNS query. This is used by NSEC3 to protect the identity of child zones

key rollover - The process of retiring a key and replacing it with a new key.
The recommended process prepublishes the replacement key prior to
removing the old key to maintain continuity with recursive validating DNS servers

key signing key (KSK) - A key that is used as the trust anchor for a
domain by publishing the key in the domain and a DS Resource Record
in it's parent zone file.

keyset-'zone' file - A collection of KSKs that are either actively signing the
zone or are prepublished to sign the zone in the future that are provided
to the parent zone to complete a chain of trust

IANA iTAR Repository - A collection of KSKs that sign top level
domains (TLDs) and are to be used as trusted keys when
configuring a recursive validator

recursive validator - a DNS Server configured to validate DNSKEYs and add
the results to DNS queries, when asked

Signature - a loose term used by this author to capture the step of annotating and 'signing' a zone file

top level domain (TLD) - a domain under the root (e.g. .gov, .com, .org, and .net)

zone signing key (ZSK) - A key that is used to sign child records in a domain
or zone

zone - synonym of 'domain'

zone file - a file containing the child records for a domain

An important step in configuring your firewalls for DNSSEC operations
is to increase the DNS message length permitted by the firewall. The
default message-length for all DNS messages in routers shipped by
Cisco Systems is 512 bytes. The average DNSKEY query response for
signed domains is approximately 2,900 bytes. This creates a symptom
that is difficult to isolate. First a UDP query will be sent and
then a second TCP query will be sent if the UDP response is
truncated. Both will fail during validation, but since .com and .net
queries are succeeding, you may think there is nothing wrong with your
configuration and call the TLD operator with the following symptom.

Symptom: DNS queries time out or fail for all queries to TLDs that
are signed (e.g. .gov, .org) using a recursive validating caching name
server. All other queries succeed so it may take a while for the
problem to get reported.

Solution: Change the message-length to 4096 for all DNS queries.

The validating name server will query the TLD and its
children for all of their DNSKEYs and place them in the cache.
This query is one of the larger DNS queries and if the firewall
does not allow the large answer through, then the name server will
attempt to resort back to non-validating DNS service. This may or
may not be successful, however, and often the validating name
server will determine that the zone is not authoritative enough
to be queried.

Examples:
CISCO product examples. All manufactures are affected, however,
so consult the manual on how to increase this size at the time
of DNSSEC deployment.

pix501 config

interface ethernet0 100full
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxxxxx encrypted
passwd xxxxxxxxxx encrypted
hostname PIX
domain-name PIX
fixup protocol dns maximum-length 4096

!-- Output for service-policy applied globally
!
firewall# show service-policy inspect dns
Global policy: 
 Service-policy: global_policy
   Class-map: inspection_default
     Inspect: dns preset_dns_map, packet 37841, drop 0, reset-drop 0
       message-length maximum 4096, drop 0
       *dns-guard, count 21691*
       protocol-enforcement, drop 0
       nat-rewrite, count 0
       *id-randomization, count 21856*
       *id-mismatch count 10 duration 2, log 2*
firewall#

!-- Output for service-policy applied per interface
!
firewall# show service-policy inspect dns
Interface outside:
 Service-policy: global_policy
   Class-map: inspection_default
     Inspect: dns preset_dns_map, packet 4923, drop 1544, reset-drop 0
       *message-length maximum 4096, drop 39*
       *dns-guard, count 2147*
       *protocol-enforcement, drop 542*
       nat-rewrite, count 0
       *id-randomization, count 2220*
       *id-mismatch count 10 duration 2, log 1*
Interface inside:
 Service-policy: global_policy
   Class-map: inspection_default
     Inspect: dns preset_dns_map, packet 240, drop 0, reset-drop 0
       message-length maximum 4096, drop 0
       *dns-guard, count 88*
       protocol-enforcement, drop 0
       nat-rewrite, count 0
       *id-randomization, count 116*
       id-mismatch count 10 duration 2, log 0
firewall#