2/4/2009 11:16:01 AM

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


NSEC (less security, allows zone enumeration)

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


You can use the free service on the www.dnssecreport.com website to
remind you change your salt and resign your zone prior to expiration date.

2/4/2009 12:14:50 PM

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

  • NSEC (less secure, allows zone enumeration)
  • NSEC3 (more secure)

    The following key algorithms SHOULD NOT be used when signing with DNSSEC
    due to the weakness of the keys:
  • RSAMD5, DH, DSA, NSEC3DSA, HMAC-MD5, and HMAC-SHA1 to HMAC-SHA512

    The gov zone is currently the only TLD signed using NSEC3RSASHA1, but .com, .net,
    and .org will someday follow suit using NSEC3 keys.

    The NSEC3RSASHA1 algorithm will be the algorithm to use for NSEC3 keys until
    the NSEC3RSASHA256 algorithm is incorporated into Bind and other dns software
    packages. NIST will then recommend all US Federal Government Agencies upgrade
    their keys to this stronger algorithm when it is available. The anticipated date is
    January 2010.

    The key type cannot be changed once a ZSK or KSK is generated. The
    dnssec-signzone command uses the key type passed to the command to
    perform either NSEC3 or NSEC zone signing.

    With NSEC signing, an invalid domain name query, for example yahoo.gov,
    would return an NXDOMAIN record and the next valid domain name in
    alphabetical order in the zone in plain text. In some zones, it is not desireable
    to 'leak' this information out to potential attackers so NSEC3 hashes the domains
    in the zone and returns a hashed value to thwart malicious attacks that may use
    this enumeration to retrieve domains from the authoritative name servers and attack
    the unsuspecting domains.

    NSEC3 was released in late 2008 and it is relatively new. However, an upgrade
    to DNSSEC should go 'all the way' and use NSEC3 to avoid 'leaking' third and fourth
    level domain names within the zone that were previously hidden. NSEC key users
    must be reminded that enumeration will be enabled when it was formerly unreachable
    prior to signing.

    To create one KSK and two ZSK 2048 bit NSEC3 keys, use the following command
    line options:


    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


    To create 2048 bit NSEC keys, use the following:


    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 ZSK keys generated are strong enough to sign the domain for 3 months.
    The KSK key generated is strong enough to act as a trust anchor for 24 months.

  • KSK Rollover

    Author: DM47
    3/6/2009 8:49:54 AM

    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.

    ZSK Rollover

    Author: DM47
    3/6/2009 9:38:01 AM

    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.

    DNSSEC Glossary

    Author: DM47
    3/9/2009 12:21:23 AM

    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#