SecSpider

In order to gain a quantitative assessment of DNSSEC as a whole, we derived three system metrics whose values range from 0 to 1. Understanding the intuition behind these metrics is important, and is covered in great detail in our IMC '08 paper Quantifying the Operational Status of the DNSSEC Deployment. We give a high level summary below, but details are presented in the full paper:

• Availability: This measures whether the system can provide all the data to the end-systems requesting it, and presents the "dispersion" seen across all pollers (i.e. can some pollers retrieve data and others not). A value of 1 means all pollers see a zone equally well (or poorly). As the value approaches 0, there is a higher degree of dispersion (or difference) between how well each poller can see the zone's data.
• Verifiability: This measures whether the end-system can cryptographically verify the data it receives. Here we represent how contiguous is the secure delegation hierarchy (1 means all zones reachable from a single root, and 0 means all zones are isolated islands of security).
• Validity: This measures whether the verified data is actually valid. Note that in an actual deployments, it does not necessarily follow that all verified data is indeed valid. Here we begin with the idea that data is either valid, or invalid, and it is either verified or not verified. Thus, when the system verifies data that is genuine we call it a "Positive Positive"), when it fails to verify false data we call it a "Negative Negative"). There are also False Negatives and False Positives.

  	Verified	Unverified
  Valid	Ideal Behavior	False Negative
  Invalid	False Positive	Intended Defense

  We present this metric as a 2-tuple:
  <Positive Positives, Negative Negatives>
  Here, <1, 1> means that all of the delegations leading to child zones are verifiable (not broken), and no zones have stale RRsets that could be used to launch replay attacks. As these numbers approach 0, they indicate a growing portion of zones that have either false negatives (broken delegation chains), or false positives (stale / replayble RRsets).

Availability:
Verifiability:
Validity:

The reason for this approach is to make SecSpider's globally distributed polling system act as a Community of Trust that can attest to keys even when the global delegation hierarchy has not rolled out or is misconfigured. The strength of this approach comes from the fact that it forces any would-be adversary to subvert all of the pollers on several continents for prolonged periods while SecSpider polls its corpus in a randomized order.

This information is loaded into our signed zone as DLV records and they can be queried for by issuing the command:

   dig <zone name>.dlv.secspider.cs.ucla.edu dlv
        

   dig se.dlv.secspider.cs.ucla.edu dlv
        

The simple 3 minute guide to enabling DLV validation using SecSpider is:

1. Make a copy of your named.conf file to be safe: cp named.conf named.conf.`date +%s`
2. Get our key-fetch script: keygrab.pl
3. Pick a place where you would like to store SecSpider's DLV trust anchor as a file (such as next to your named.conf file). Say: /etc/named/secspider-trust-anchor.conf and then run the keygrab.pl:

     ./keygrab.pl > /etc/named/dlv-secspider-trust-anchor.conf
                 

4. Open you named.conf file in a text editor and modify the options{ } section of this file and add (or make sure to include):

     dnssec-enable yes;
     dnssec-validation yes; // BIND 9.4 and later 
     dnssec-lookaside . trust-anchor dlv.secspider.cs.ucla.edu;
               

5. Next (while still in named.conf), add a line (outside the options{ ... } block to include the SecSpider trust anchor:

     options {
       ...
     };
   
     include "/etc/named/secspider-trust-anchor.conf";
                 

6. Exit the editor and make sure BIND understands the conf file: named-checkconf named.conf
7. If there were no complaints, restart BIND and you should be verifying!
8. Once you are happy, it might be a good idea to re-fetch the SecSpider key every so often. You can cron the above keygrab.pl command and restart your BIND server periodically.

When we crawl our list of zones, we also test each zone to see if it has been configured with either a "www" A record, or an MX record, and if either of them are online and accepting connections. Any zone that meets these criteria is considered a "Production" zone. In order to correct for zones that are in production, but are missed by our automated tests, we offer the option for users to specify that a zone is production (regardless of whether is has a www or MX record, etc.).