[dns-operations] Unplanned DLV zone outage on 2009-Apr-06

[Eric Osterweil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 14, 2009, at 3:27 PM, Lutz Donnerhacke wrote:

> On Tue, Apr 14, 2009 at 03:59:57PM -0400, Hugo Salgado wrote:
>> Lutz Donnerhacke wrote:
>>> There are other DLVs out there, i.e. dlv.vulcano.cl.
>>
>> hey! that's my sandbox zone. it's just a test, preparing myself
>> to bypass the unforeseeable .cl signed zone ;)
>
> Hi, welcome to the club of DLV operators.
>
>> by the way, here's another production dlv repo:
>>  http://secspider.cs.ucla.edu/faq.html#dlv
>
> I mentioned SecSpider as a DLV, but not a TAR. They do not claim and  
> do not
> want their DLV view of their database to be used as a trust source.

I think SecSpider is quite useful to resolvers.  Both its DLV repo and  
especially its trust-anchors file ( http://secspider.cs.ucla.edu/trust-anchors.conf 
  ).

I'm not sure why you're making such a big distinction of "TAR" or  
not.  This seems a rather artificial distinction to me...  What I  
think a resolver should want to know is if the DNSKEYs it sees for a  
zone are those actually being served by that zone?

Thus, I think SecSpider is quite useful for this.  Our assertion is  
simply that the keys we serve are those that have been observed from  
our distributed polling infrastructure.  We poll our corpus from  
multiple points on several continents and only publish keys that are  
consistent across all pollers using the name servers from both the  
parent zone's view of the NS RRset and those name servers' views of  
the NS RRset.  We claim that this is the "public" view of keys and  
that an adversary would have a phenomenally difficult time spoofing  
all of our pollers, from all of a zone's name servers, at the precise/ 
random time that we poll (we do not use caches).  Thus, our security  
model revolves around making decisions based on global key consistency.

However, I believe that downloading our trust-anchors file ( http://secspider.cs.ucla.edu/trust-anchors.conf 
  ) is a much more operationally viable choice as it lets all  
verification happen locally rather than through a look-aside to a 3rd  
party.

Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAknlCCoACgkQK/tq6CJjZQL+EwCghSqvDc/wUqkbnnWJ23QzaiPO
8c8Anix7sS8CHiPBZTcpFygn8zW/Upfq
=LS5O
-----END PGP SIGNATURE-----