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.