About

Frequently Asked Questions (FAQ)

Usage

Publications

Presentations


Frequently Asked Questions (FAQ)

Q: Who is in charge of SecSpider?
A: 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
Q: What are the DNSSEC deployment metrics?
A: 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:

Verifiability:
Validity:

Q: What does consistency mean?
A: 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 inconsistent.
Q: What is a stale RRset?
A: 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."
Q: How do you determine DNSKEY lifetime?
A: The RRSIG attached to the DNSKEY RRset determines the DNSKEY lifetime.
Q: How do you determine islands of trust?
A: 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.
Q: What is a "Production" zone?
A: 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 record, etc.).


About

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-4034, 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:

  • 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
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.


Usage

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.

Aggregate Statistics

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.

Zone Drill-downs

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:
  • 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.
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 zone is.

Below this header are several links to flat data files. These files are:

  • DS records for this zone
  • DNSKEY records for this zone
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

<zone name> <keytag> <DS fingerprint> <# RRSIGs> <RRSIG signature>[ <signature>...] <n>/<m> <pollers>

DNSKEY Records

<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 in question.

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.