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
  ,
and this was our latest opportunity: .
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.
SecSpider at IETF 75
Wed, 12 Aug 2009 14:04:25 PDT
< Comments >
Recently there have been some notable outages of popular DNSSEC DLV repositories:
, 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 3rd 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:
The Sky is NOT Falling, but...
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
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 >
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!
SecSpider at the CATCH Conference
Tue, 10 Mar 2009 13:38:20 PDT
< Comments >
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!
Check YOUR Zone's Status!
Wed, 25 Feb 2009 20:32:31 PST
< Comments >
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
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
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.
Trusted Key File Now Available!
Tue, 24 Feb 2009 09:55:33 PST
< Comments >
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.
Trust Anchor Learning
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 >
The new distributed version of SecSpider has been released. Now all zones are polled from polling locations around the world.
Please check us out. We also use our GPG key to sign for all the DNSKEY RRsets that we see across all of our pollers!
Wed, 10 Oct 2007 00:00:00 PDT
< Comments >