DNSSECReport.com

A new DNSSEC component that must be purchased, upgraded, or outsourced is the DNSSEC Recursive Validator. This is an instance of Bind, Unbound, or equivalent software that is capable of validating public keys with DNS servers that have signed the zone with a corresponding private key. Existing recursive validators may be upgraded, but first the OS must be upgraded with the latest security patches, hardened using FIPS PUB 800-81R1, and finally reconfigured to validate public/private keys.

DNSSEC will be deployed in the USA during 2009 and will become a standard means for establishing trust among organizations. There will be a handful of DNS servers for each large government agency or corporation that will be specifically configured to validate the DNSSEC keys and cache the DNS results. These servers will need to capture the successful and unsuccessful key validations and assist system administrators with the diagnosis of failed keys and halted email and web traffic as a result.

During these times of organization panic, it will be helpful to have configured your Recursive Validators with the proper settings to minimize potential problems and speed the diagnosis of trouble. Below is a set of configuration settings for Bind 9.6.x that attempts to meet these goals.

Step #1 - Enable recursive validation

Use the following in named.conf to enable recursive validation in bind:

options {
    recursion yes;
    dnssec-enable yes;
    dnssec-validation yes;
    allow-query { any; };
    allow-recursion { any; };
    ...
}

Step #2 - Configure the trusted keys to be used for validation

Import the keys you wish to obtain trusted communications with to minimize the risk of DLV poisoning and to keep your DNS queries and destinations private to your organization.

trusted-keys {
  $include /etc/bind/dnssecreport-daily.txt  ; scrubbed/tested keys
}

Step #3 - Update your named.conf to capture failed validations

        logging {
    channel dnssec_log {
    file "dnssec.log" size 100m;
    print-time yes;
    print-category yes;
    print-severity yes;
    };

        channel keycheck_file {
            file "validation.log" versions 5;
            severity debug 3;
            print-category yes;
            print-severity yes;
            print-time yes;
        };

        category dnssec {dnssec_log; };
        category security {dnssec_log; };
        category default {default_syslog; keycheck_file; };
        category general {default_syslog; keycheck_file; };
        category update {default_syslog; keycheck_file; };
  
};

Step #4 - download trusted keys for validation
Use the following command line to obtain the trusted keys on a daily or weekly schedule:

   cd /etc/bind
   wget http://www.dnssecreport.com/DNSSECReport/dnssecreport-daily.txt
   /usr/sbin/named restart

All of the published public, trusted keys will be loaded into memory and
be ready for validation.

Step #5 - Test your recursive validator

You can test the validator using the following command line:

   dig +dnssec A www.dotgov.gov @localhost

In the HEADER section, you should see the following NOERROR
status:

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1424

Errors such as SERVFAIL mean the keys may be improperly signed or expired.
If there is no DNSSEC information returned, then you may be running an old version of DNS software that is not aware how to validate NSEC or NSEC3 keys.

To quickly create a list of failed keys in the logs, use:

  grep 'validation failed' dnssec.log > myfailedvalidations.txt
  grep success dnssec.log > mysuccessfulvalidations.txt

Please email support@dnssecreport.com with any updates to this guide.

The addition of the NSEC3RSASHA1 algorithm for key generation
added additional security to the signing of zone files. This
security changes the results computed for NXDOMAIN for the signed
zone file to hash the child domain names. This hashing eliminates
the ability for a zone crawler, or spider, to identify all the child zones
programatically and launch and attack.

In Bind 9.6.0 and later releases, two new parameters are passed to
the dnssec-signzone command to hash the child names during the
signzone process:

    -H (int) -3 (Hex[4])

An example zone signing would be:

    dnssec-signzone -H 15 -3 aabb -k Kdomain.net.+007+56487 \
    -o domain.net -e +7776000 domain.net Kdomain.net.+007+62648

There is a potential problem with this hashing that could enable a successful
denial of service (DoS) attack against the authoritative name server by
repeatedly asking for children that do not exist in the zone. The
authoritative name server would need to hash the incorrect names to locate
a match in the zone file. This risk can be reduced by applying the following
rules:

Keep the hash number below a threashold of 100.

This number will reduce the amount of CPU cycles per query and allow the
authoritative name server more time to handle the attacker's load.

NOTE: Keys generated using the NSEC3RSASHA1 algorithm may be used to
sign a domain with enumeration enabled (NSEC). Simply omit the -H and
-3 parameters in the dnssec-signzone command to generate the NXDOMAIN
records in clear text.

To move from an unsigned zone to a DNSSEC signed zone, the
following changes are necessary to the named.conf (or $include files).

The signed zone, 'domain.net.signed', will be the new zone file that
should be present in named.conf. The prior file should be edited offline
and used as input to the DNSSEC zone signing process.

zone "domain.net" {
     type master;
     file "domain.net.signed";
};

Next, add the following command to the named.conf options
statements:

options {
  ...
  ...  
        dnssec-enable yes;
};

Next, add the following command to the named.conf options
statements:

options {
  ...
  ...  
        dnssec-enable yes;
};

Next, restart the bind service using the appropriate command or tool.

You are now ready to test the signatures.

NOTE: Statements like the following that were added to the unsigned zone
file:

$include Kfed.gov.+007+55791.key ; Active Key Signing Key
$include Kfed.gov.+007+08345.key ; Active Zone Signing Key
$include Kfed.gov.+007+44198.key ; Prepublished Zone Signing Key

will be removed by the dnssec-signzone command. Do not attempt to add
or change the contents of the ."signed" file. To update the zone, change the
unsigned file and resign the unsigned file.

There appears to be a large number of firewalls that are
not configured to handle the large DNS message sizes necessary
for DNSSEC. ALL reports on DNSSECReport.com have been updated
to test the firewalls in front of each name server to see
if there are dropped packets due to size.

Test patterns:

  dig domain.gov DNSKEY @authoritative-nameserver

The above command line is way to simulate the test performed
by DNSSECReport.com. This will attempt to pull a large block
of data through the firewall and see if it is stopped for any
reason.


Success!:

If we receive >1500 bytes in the resulting message, we
score the test as successful. However, if you later
add DNSKEYs to the zone to a point where the DNS MSG
SIZE of the firewall is exceeded, then this success will
need to be increased. 2800 bytes should support a KSK,
ZSK, and 2 prepublished keys. A recursive resolver will tend
to ask for all DNSKEYs in a single request and the full
result set must make it through the firewall otherwise
the client side validation will not succeed. If your firewall
is blocking DNS messages, your network (and also
this www.dnssecreport.com website!) appears VERY SLOW
due to the DNS UDP and TCP timeouts. In fact, it is
your name servers that are slowing external internet
browsing so this issue should be fixed ASAP.


Fail:

There will be many false falures. Unsigned zones may not
have enough data in the zone to reach any limit set by the
firewall manufacturer. Recursion may be turned off and this
may stunt the results. One way to get good results is to
turn recursion on briefly for the test. A second way to get
accurate results is to prepublish 2 ZSKs plus a KSK and
ZSK keys in a delegated test zone, sign and run the report at
DNSSECReport.com. If there is a configuration problem,
it will be detected for any DNS response returning through
the firewall and the result will likely be '0' bytes.

See the Cisco IOS and other suggested changes on the home
page of DNSSECReport.com for instruction on increasing the
DNS message-length in a variety of firewalls.