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

Eric Osterweil eoster at CS.UCLA.EDU
Tue Apr 14 22:44:43 UTC 2009

Hash: SHA1

On Apr 14, 2009, at 4:16 PM, Jeremy C. Reed wrote:

> On Tue, 14 Apr 2009, Eric Osterweil wrote:
>> 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.
> How often are they verified?

We crawl 2-3 times per week.

> What happens if the unknowing zone decided to become unsigned but  
> the DLV
> still indicates that it should be signed? (Due to no relationship and
> communication with the DLV.)

We only serve keys that were seen during the last poll and that have  
valid RRSIGs (i.e. if they've expired we don't list them).  If a zone  
signs for (say) a month, and then removes its signed material the next  
day, that's already a bit of a faux pas.  Something like that can  
cause a lot of problems for that zone if data is cached somewhere, or  
if someone wants to replay data into a cache w/ the still valid RRSIGs  
anyway.  We will stop listing the keys, however, if they are not  
present the next time we crawl.

Version: GnuPG v2.0.9 (Darwin)


More information about the dns-operations mailing list