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

Michael Sinatra michael at rancid.berkeley.edu
Tue Apr 14 23:50:28 UTC 2009

On 4/14/09 3:44 PM, Eric Osterweil wrote:

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

There's a big difference between signing and placing a trust anchor 
somewhere where you *know* people will use it and then unsigning your 
zone and leaving the trust anchor in place, versus placing a signed zone 
into production with no trust anchors anywhere (==an insecure zone).  In 
the first case, you have created a broken zone, and you should know that 
you have done so.

In the second case, you have created an insecure zone which you have not 
explicitly asked anyone to trust.  But then someone comes along and 
scrapes your zone without your knowledge and puts the keys in a 
repository that others trust.  Now you're in a situation where people 
are trusting your DNSSEC without your knowledge.  If I assume nobody is 
trusting my zone, is it really that big a faux pas to un-sign it or 
change the signing keys?  Or is it a bigger faux pas to create a 
mechanism where people trust my zone without my knowledge?  (I hope that 
  this is not the way SecSpider works.)

Consider another example: Someone spoofs a zone in such a way that all 
of your pollers get the same key information and SecSpider regards that 
information as valid.  Now there is a trusted fake zone with bogus 
information that users of SecSpider regard as "secure."  Unlikely 
scenario, but it seems that it is a much better idea to have key 
management done out-of-band from the DNS protocol itself.

I can see where SecSpider would have use in testing and research, but I 
assume you're not advocating it for production use.


More information about the dns-operations mailing list