[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.
michael
More information about the dns-operations
mailing list