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

[Mark Andrews]

In message <EFE30A3F-AB88-48C1-AA2C-2413FE97E10B at CS.UCLA.EDU>, Eric Osterweil writes:
> >
> > 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:
> >>>
> >>> 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.
> 
> <snip>
> 
> Ignoring flame.

	What flames?

	Until a zone has declared that it is using DNSSEC in a
	operational manner it shouldn't matter what the operator
	does.  GOV was a perfect example of a operator changing
	things willy nilly up until it declared the zone was signed.
	DNSKEYs that worked one day didn't the next.
 
> > 	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.
> 
> Unsigned parent?

	I didn't say that *all* methods were applicable to all
	zones.  Publishing a parent is only possible if the parent
	is signed.
	
> > 	* provide DS/DNSKEY to DLV, key changes are now constained by DLV/ 
> > zone
> > 	  relationship and associated TTLs.
> 
> Which DLV?  Does everyone have to agree to use only 1?

	You can publish in multiple DLV's. 
 
> > 	* publish the DNSKEYs via HTTP and provide the roll over mechanism  
> > details.
> 
> How does any given resolver learn of your zone's web page?

	This is where scraping could be useful.  It gives you a *hint* to
	look for published trust-anchors. 

> > 	* publish the DNSKEYs in the newspaper and provide the roll over  
> > mechanism
> > 	  details.
> 
> ibid.
> 
> >
> > 	* publish the DNSKEYs via a TAR, key changes are now constained by  
> > the TAR's
> > 	  refresh policies.
> 
> I'll refrain from discussing things that don't exist yet.

	Except they do.

	For my zones I publish in the parent and in ISC's DLV
	depending apon whether the parent is signed or not.  For
	those parents that arn't signed I'm encouraging them to get
	signed.  I don't publish on the web.

	Mark
 
> Eric
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org