SecSpider the DNSSEC Monitoring Project
Home | Blog | About | FAQ | Documentation | Usage | Pollers | GPG Key | IRL

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.

Datasets

Our datasets are free available (simply contact any of the development team members for access).
Back