<?xml version="1.0" encoding="UTF-8" ?>

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<atom:link href="http://blog.secspider.cs.ucla.edu/rss.xml" rel="self" type="application/rss+xml" />
<title><![CDATA[SecSpider Blog]]></title>
<link><![CDATA[http://blog.secspider.cs.ucla.edu/]]></link>
<description><![CDATA[This is the official SecSpider DNSSEC blog]]></description>
<ttl><![CDATA[60]]></ttl>
<language>en-us</language>
<managingEditor>spam@secspider.cs.ucla.edu</managingEditor>



<item>
<title>SecSpider at IETF 75</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1250111065</link>
<description><![CDATA[  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.

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1250111065]]></comments><pubDate><![CDATA[Wed, 12 Aug 2009 14:04:25 PDT]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1250111065</guid>
</item>

<item>
<title>The Sky is NOT Falling, but...</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1239742705</link>
<description><![CDATA[  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 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:
  
    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!

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1239742705]]></comments><pubDate><![CDATA[Tue, 14 Apr 2009 13:58:25 PDT]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1239742705</guid>
</item>

<item>
<title>SecSpider at the CATCH Conference</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1236717500</link>
<description><![CDATA[  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!

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1236717500]]></comments><pubDate><![CDATA[Tue, 10 Mar 2009 13:38:20 PDT]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1236717500</guid>
</item>

<item>
<title>Check YOUR Zone's Status!</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1235622751</link>
<description><![CDATA[  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!

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1235622751]]></comments><pubDate><![CDATA[Wed, 25 Feb 2009 20:32:31 PST]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1235622751</guid>
</item>

<item>
<title>Trusted Key File Now Available!</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1235498133</link>
<description><![CDATA[  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.

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1235498133]]></comments><pubDate><![CDATA[Tue, 24 Feb 2009 09:55:33 PST]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1235498133</guid>
</item>

<item>
<title>Trust Anchor Learning</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1205343091</link>
<description><![CDATA[  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.
  

]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1205343091]]></comments><pubDate><![CDATA[Wed, 12 Mar 2008 10:31:31 PDT]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1205343091</guid>
</item>

<item>
<title>SecSpider 2.0!</title>
<link>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1205328251</link>
<description><![CDATA[  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!
  
]]></description>
<author>spam@cs.ucla.edu (Eric Osterweil)</author><comments><![CDATA[http://www.cs.ucla.edu/~eoster/blahdot/cgi-bin/topic.cgi?id=1205328251]]></comments><pubDate><![CDATA[Wed, 10 Oct 2007 00:00:00 PDT]]></pubDate>
<guid>http://blog.secspider.cs.ucla.edu/t/topic.cgi?id=1205328251</guid>
</item>

</channel>
</rss>
