SecSpider Blog

SecSpider the DNSSEC Monitoring Project

SecSpider at IETF 75

Two weeks ago the SecSpider team went to IETF 75 (in beautiful Stockholm, Sweden). The meeting was, as usual, a tremendous amount of fun. However, the DNSSEC work that was discussed was of critical importance. We continued to try and raise awareness of the Path Maximum Transmission Unit (PMTU) problem that we discovered. We have been presenting our results and writing them up with our conclusions at every opportunity [1] [2] [3], and this was our latest opportunity: [4].

This presentation gave us the chance to announce our new command-line tool dnsfunnel that lets people measure PMTU problems from their own location(s) to any zones. The tool is bundled with the entire Vantages suite, and can be downloaded here. When users install the suite, in addition to dnsfunnel and dnskey-grab they also get the new key verification TAR and can optionally run it on a machine running a recursive resolver in order to generate their own trusted-keys list.

We were hoping that our brief presentation would spark useful conversations during the working group session. Luckily the conversations in the hallways were very fruitful. With the release of dnsfunnel we hope that people can appraise the seriousness of the PMTU problem for themselves.

Wed, 12 Aug 2009 14:04:25 PDT

< Comments >

The Sky is NOT Falling, but...

Recently there have been some notable outages of popular DNSSEC DLV repositories: [1], [2], etc. These failures don't necessarily denote any lack of diligence on the part of the operators. Rather, these outages reinforce that operational missteps are a reality for Internet systems (any Internet system). As such, this really calls into question whether one should be building in a single point of failure into DNSSEC, such as DLV. A recent fiber cut in the Bay Area helps to underscore that any single operational group can be a victim of a determined attacker and any dependent parties can thereby share their fate.

As a result, this seems to be quite an opportune moment to restate our beliefs on the SecSpider project: trust-anchors should be locally configured and loaded into resolvers so that secure look-up decisions do not involve any in-line 3^rd parties. Furthermore, we should not forget that using a DLV repository tells the DLV operators more about your DNS traffic patterns than even root operators know. However, if your ability to verify DNSKEYs fails because of an error in someone's Python script, you may be wondering if you have an alternative.

-- well --

You do... Download our ta-grab.sh script and use it to download SecSpider's trust-anchor list from a cron-job. For example:

    0 0 * * * /usr/local/bin/ta-grab.sh

Presto, you're done... This script will download the TA file from SecSpider, check to see if it has changed from the last time, and if so, restart your unbound resolver. All you need to do is configure unbound to load the BIND-formatted trusted-keys file:

    trusted-keys-file: "trust-anchors.conf"

and you're all set. The script is very simple and very modifiable (in case you want any changes). Furthermore, while this simple script will get you started today, you can use it to get the TA file and then make any local modifications that you like. Now, you won't be affected by anyone's outages and you can still stay abreast of TA changes!

Tue, 14 Apr 2009 13:58:25 PDT

< Comments >

SecSpider at the CATCH Conference

The SecSpider team was in Washington D.C. last week for the Cybersecurity Applications and Technologies Conference for Homeland Security (CATCH) conference. There were several interesting types of security work presented that ranged from BGP routing security to Botnets research to (of course) DNSSEC. Among the high points were the presentations by Secure64 and Sparta. Secure64 presented a rather clear view of the threats the Internet faces without DNSSEC and discussed their one-click solution to turning anyone's plain old DNS zone into a DNSSEC zone. Their solution really is quite impressive. In addition, Sparta presented their very comprehensive toolkit of open-source tools to make everyone's life a lot easier when they manage DNSSEC on a shoe-string budget. Together these groups cover the spectrum of operational environments that need to get up to speed on DNSSEC. It was great to see the synergy!

In addition to the very complete and well done solutions presented by both of these groups, Secure64 raised the bar by hinting at some sort of upcoming service that they hope will further invigorate the deployment of DNSSEC. Details are pretty sparse, but anytime a vendor who has recently garnered the deal to provide services for organizations like Afilias (i.e. .org) says they have something "big" coming, you can't help but wonder what's next?!?

We'll post here as details become clear!

Tue, 10 Mar 2009 13:38:20 PDT

< Comments >

Check YOUR Zone's Status!

For some time now, SecSpider has been tracking many more stats about zones than the zone drill-down pages show. In particular, we have been tracking the "availability" of each zone for quite some time. We define availability as a metric that summarizes if there are any PMTU problems getting DNSKEYs from a zone from any of our pollers. In our recent IMC paper we formally measured this across all of our observed production zones, and found that roughly 20% of the observed production zones suffer some degree of availability problems. This basically means that in some cases, some resolvers simply cannot get the DNSKEY RRsets for a zone!

Now, we list the availability and stale RRset counts for each zone on their zone drill-down page. This means that zone administrators can now check if their DNSKEY RRsets are exacerbating any PMTU problems.

Please give us any feedback that you have!

Wed, 25 Feb 2009 20:32:31 PST

< Comments >

Trusted Key File Now Available!

Recent feedback given to us has suggested that facilities like DLV repositories may be a difficult pill for some operators to swallow. After all, it doesn't matter whose DLV repo you use, they get to see all of your DNS traffic after that (modulo RRset TTLs). Hopefully they don't go off and share it with others, but how would anyone know? Our thoughts on this were recently broached on the DNSSEC-Deployment Initiative's mailing list here.

As a result of this sort of feedback, and in keeping with our feelings that operators should be able to benefit from SecSpider w/o blindly trusting it, we now offer a BIND formatted trust-anchor file. This enables anyone who runs a recursive resolver to use an include pragma to configure their recursive resolver to use SecSpider's keys. Moreover, anyone can make any additions or subtractions to this file and keep all of their verification traffic local. No more DLV snooping! ;)

We suggest that anyone interested in getting the benefit of verified keys into their resolvers consider downloading this file (which is regenerated after every SecSpider run) and using it asap.

Tue, 24 Feb 2009 09:55:33 PST

< Comments >

Trust Anchor Learning

SecSpider has been enhanced to help obtain DNSSEC public keys and especially trust anchors. Using the standard DLV record type, you can now retrieve public key and trust anchor information from secspider.cs.ucla.edu.

The secspider.cs.ucla.edu. DLV records are obtained from our existing DNSSEC crawl (once per day). We have pollers in several locations in different organizations, different continents, and so forth and each poller attempts to obtain a DNSKEY RRset from a zone. The secspider.cs.ucla.edu. zone only includes DLV records for DNSKEY RRsets that are consistent across all pollers for a zone. Specifically, for each zone polled by SecSpider, the DNSKEY sets must be consistent across all pollers except pollers that were unable to see any keys at all (failed pollers). If a zone is seen to have different DNSKEY sets from different pollers, or serves expired keys, the values are not entered into secspider.cs.ucla.edu. In essence, this zone only has DLV records for DNSKEY sets that are the same from all online pollers in SecSpider.

To query secspider.cs.ucla.edu type:
dig <zone_name>.dlv.secspider.cs.ucla.edu. dlv
- or -
dig se.dlv.secspider.cs.ucla.edu. dlv

We hope that zone administrators will be willing to periodically query SecSpider to find out if their DNSKEY sets are accurately seen by SecSpider's pollers (and of course let us know if any issues or concerns). Furthermore, we hope this new zone will be a useful service for people to check if the DNSKEYs that their resolvers have match the view seen from SecSpider's distributed vantage point.

SecSpider polls its list of zones every night, and generates and signs secspider.cs.ucla.edu. afterwards. If you would like to be added to SecSpider's polling, please visit us at: http://secspider.cs.ucla.edu/ and register. Submitted zones will be added to the next morning's crawl.

Most importantly, we are eager for feedback! Specifically (but not limited to) is there another view that would be useful? Is there more information that would make it easier to produce subsets of this list of DLVs. What subsets would be useful, etc.

Wed, 12 Mar 2008 10:31:31 PDT

< Comments >

SecSpider 2.0!