Frequently Asked Questions (FAQ)
||Who is in charge of SecSpider?
My name is Eric Osterweil, I have maintained @SecSpider since 2005,
when it started crawling. Feel free to send me any
notes or comments: eoster@ gmu.edu or @SecSpider
||What are the DNSSEC deployment metrics?
The SecSpider monitoring system gathers a vast volume of data on DNSSEC resource record sets (RRsets) as viewed from different
locations over different times. This data allows researchers to investigate specific questions such as "was RRset X available
from pollers in Asia on January 31, 2008?" But the vast volume of raw data is complex and even its volume can potentially
mask any insight into how the overall system is performing. The situation is analogous to monitoring BGP routing, another
Internet-scale system. BGP monitoring project s such as Oregon RouteViews provide
invaluable raw data containing millions (if not billions) of BGP updates. Hidden in this data are important lessons about the
overall system behavior, but simply looking at raw BGP update logs does not directly answer the question of how well BGP is
performing. Similarly, simply presenting millions of DNS RRset query results does not directly answer the question of how well
DNSSEC is performing, how effective it may be in providing cryptographic protections for the DNSSEC-enabled zones, and more
importantly, how these measures may be changing over time.
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:
The equations used to calculate these metrics are fully described in the paper, but are shown here as a starting point:
- 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.
We present this metric as a 2-tuple:
|Valid||Ideal Behavior||False Negative
|Invalid||False Positive||Intended Defense
<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).
||What does consistency mean?
The consistency is the percentage of active pollers who found
identical data for a given data set. If any data item from a set of
data observed by the pollers differs, those sets are considered
||What is a stale RRset?
A stale RRset is an RRset that is vulnerable to replay. This
occurs when an already-signed RRset is resigned while it's previous
signature is still valid AND the new RRset has new values. An example
would be if a DNSKEY set is signed for a month, and during that month
(say on day 2) an existing DNSKEY is replaced (or the set is just
augmented with a new DNSKEY). In any similar case, the RRset has
changed, but the old signature will still verify it for the remainder
of the month. We call this set "stale."
||How do you determine DNSKEY lifetime?
The RRSIG attached to the DNSKEY RRset determines the DNSKEY lifetime.
||How do you determine islands of trust?
We trace all trust delegations (i.e., DS records) as far up the DNS
hierarchy as possible. Once we reach a zone whose parent does not
contain a DS record, we consider that zone the trust anchor for an
island of trust. All zones for which there is a delegation chain from
that anchor are considered parts of the island.
||What is a "Production" zone?
SecSpider attempts to separate DNSSEC test zones from those that seem
to be production. The goal is to aid people in finding information
about zones, and to differentiate between behaviors seen in actual
deployments, and test-zone behavior.
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
The global Domain Name System (DNS) has functioned as the Internet's de facto name resolution system since the 1980's. Its design
goals centered around systems and operational issues and did not account for very many security issues.
More recently, the DNS Security Extensions (DNSSEC) have been proposed (RFC-4033,
RFC-4035). The deployment efforts of DNSSEC are described in many places, including
the DNSSEC Deployment Initiative.
To aid people's understanding of the size, scope, and trends of the global rollout of DNSSEC, as well as operating as a distributed key lookup service, the SecSpider project has maintained
a historical view of various information about zones since early in 2005.
The list of zones that SecSpider uses is a combination of zones that have been submitted by users (via the online submission
form), crawled from a large list of over 2.5 million zones, and walked (via NSEC walking).
SecSpider interrogates zones for certain data and behaviors and then classifies them as "secure" or not. In order for a zone to be
identified as secure all nameservers that serve the zone must meet the following criteria:
Zones that meet these criteria on all of their nameservers are then considered "secure."
SecSpider is a globally distributed polling system that crawls its list of secure zones once every day. Its
pollers are distributed in order to verify that observed data is consistent from various locations and
is robust against any local network effects or phenomenon.
- Must support EDNS0
- Must have RRSIG records attached to resource record sets (RRsets)
- Must not have a CNAME for the zone's domain name
- Must provide NSEC records for denial of existence
The SecSpider website is designed to service as many different needs as possible. The website attempts to provide several
focused views of the DNSSEC deployment that may be of interest to various parties. SecSpider presents 2 types of data about
the DNSSEC deployment. The first type (presented on the main page) is a set of aggregate statistics about about the entire
list of monitored zones. The second type is zone-specific data that is described on an individual drill-down page for each zone.
On the main page we list the size of our monitored set under the "Monitoring Summary" section. In addition to this
we provide a count of the number of zones that "have NS sets that match their parents' delegation set." This number
represents the list of zones whose parents have listed the same nameservers as the authoritative zones. This number is intended
to be useful to those who study the incidence and impacts of "lame-delegations" in DNS.
Below this data is the count of DNS zones that meet our criteria for being classified as DNSSEC enabled,
and a count of how many secure zones use both a KSK and a ZSK.
The next section on the main page details different information about the DNSKEYs observed. SecSpider tracks the different
cryptographic algorithms used by keys and the key lifetimes (derived from the accompanying RRSIGs). On the main page, there
is a table called "Distribution of key algorithms in use" that lists the breakdown of the counts of different
key algorithms observed. To the right is a plot showing the distribution of lifetimes of all keys.
On the top-right of the main page is a graph showing the number of zones as a function of the number of vulnerable RRsets
that exist for them. This number is detailed more on each zone's drill-down page, but the figure shows how many zones have
stopped serving RRsets whose lifetimes are still valid. This is discussed below.
At the bottom of the main page is a plot that shows the distribution of sizes of "Islands of Security." This
plot shows the number of zones that belong to an island of a certain size. The image, itself, links to a page that actually
shows the roots of each island.
One of SecSpider's central tasks is to interrogate DNS zones and determine if they are DNSSEC enabled, or not. To do this,
SecSpider uses the following criteria:
Zones are only considered secure if all of their online nameservers pass the above checks.
Each Zone is listed as DNSSEC enabled, or not, and there is a link to its drill-down page.
At the top of each zone's drill-down page, there is a timestamp the indicates the last time the zone was crawled.
Below that is a percentage that indicates how many of SecSpider's distributed pollers were able to crawl the zone.
Under that, users can see the reason a zone is being monitored (user request, crawled, etc.), and what the name of the parent
Below this header are several links to flat data files. These files are:
- A zone's nameservers must support EDNS0.
- A zone's nameservers must return RRSIG records with data when the DO bit is set.
- Returned RRSIGs must correspond to DNSKEYs that are also served by the zone.
- The zone must not have a CNAME for it's apex.
- The zone must return NSEC records for names that do not exist.
Each of these files is also signed with SecSpider's site key (a GPG key). Signed files are
linked separately from the flat files.
The purpose of these files is to aid users in looking up DNSKEYs easily. SecSpider's distributed framework offers users
the unique ability to verify that DNSKEYs they have received from a zone match those seen from distributed pollers around the World.
Moreover, SecSpider's flat files also list the degree of agreement/disagreement that its pollers have about keys, and the specific
pollers that have seen this data. For example, a key
may have been seen by 4 out of 4 pollers, whereas another key may have been seen by 3 out of 4 pollers, and in both cases a comma
delimited list of these pollers terminates the line. This information is all
encoded in the flat files, and on the zone's drill-down page.
These files have a GMT timestamp alone on their first line, and all lines below that follow the format:
- DS records for this zone
- DNSKEY records for this zone
<zone name> <keytag> <DS fingerprint> <# RRSIGs> <RRSIG signature>[ <signature>...] <n>/<m> <pollers>
<zone name> <keytag> [KSK|ZSK] <Algorithm> <DNSKEY text> <n>/<m> <pollers>
In each of these formats, <n>/<m> indicates that "n" out of "m" pollers observed this value.
The next table on the drill-down page is a list of trust anchors for the zone. Trust anchors are used as points of verification.
Often a parent zone is expected to verify its children (if they are
all DNSSEC enabled). Trust anchors are zones that use their own DNSKEYs to verify that a DNSKEY actually belongs to the zone
The table below this is the DS record table. This table lists the keytag, fingerprint and result of verifying if the record actually
matches its corresponding DNSKEY.
Below the DS table is the DNSKEY table. This lists the actual DNSKEYs for the zone, their type (KSK/ZSK), the algorithm they
use, and the RRSIG information that gives the keys their lifetimes.
The final table on the page is RRsets table. This table lists the types, inceptions, and expirations of all RRsets that are
still valid (i.e. their inception and expirations are still valid), but are no longer served by the zone. Moreover, the
table also lists whether the values of each RRset differ from those currently served by the authoritative zone. If so, the
records are potentially vulnerable to spoofing.