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

[Mark Andrews]

In message <F095B7FC-F8BF-4E89-847A-B77EA42E3C8C at CS.UCLA.EDU>, Eric Osterweil writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

	Garbage.  If I'm testing and the only person I've told that I'm
	using DNSSEC is myself then I can do whatever I want to a zone
	without impacting anyone else but my self.  I just need to make
	sure my experiments have cleared caches before going operational.

	When I publish trusted keys then I need to consider other people.
	Until I publish trusted keys I don't need to consider other people.

	I can publish trusted keys in multiple manners.
	* provide DS/DNSKEY to parent, key changes are now constained by parent/child
	  relationship and associated TTLs. 
	* provide DS/DNSKEY to DLV, key changes are now constained by DLV/zone
	  relationship and associated TTLs.
	* publish the DNSKEYs via HTTP and provide the roll over mechanism details.
	* publish the DNSKEYs in the newspaper and provide the roll over mechanism 
	  details.
	* publish the DNSKEYs via a TAR, key changes are now constained by the TAR's
	  refresh policies.

	Mark

> 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.

 
> Eric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (Darwin)
> 
> iEYEARECAAYFAknlEdsACgkQK/tq6CJjZQLfwACdGOpxN+mkHjwOGBu4ZhtibJx7
> mSMAn2/tMUMjfLnrIBDDa1I7H8AKU9Tg
> =0lTt
> -----END PGP SIGNATURE-----
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org