michael at rancid.berkeley.edu
Wed Jan 4 20:18:31 UTC 2012
On 01/04/12 12:05, Bill Owens wrote:
> On Wed, Jan 04, 2012 at 11:04:37AM -0800, Craig Leres wrote:
>> Does anybody have a contact for BNL? Their zone is not signed with any
>> of the keys found in gov. This has been broken for at least 24 hours
>> now. I called their help desk yesterday around 1:30pm PST but I guess I
>> wasn't able to convey how serious this issue is.
> I happen to have a contact at BNL and just spoke with him - they became aware of the problem from your email yesterday and opened a ticket with the .gov admins to have the DS record updated, but it hasn't been done yet (obviously). He also mentioned that there's an 'automatic' setting for this, something I hadn't heard of before, but bnl.gov is not set up that way.
> At any rate, they do know, and they are taking it seriously, but at this point they're waiting for the fix. . .
They should still be signing their DNSKEY RRSET with key 63541, EVEN
AFTER gov inserts the proper DS record. That's because many DNS servers
still have the old DS record cached (its TTL is 24 hours). Just as an
example, even if it's fixed now, my home DNS server will continue to
cache the old DS record for another 12 hours.
Of course, since the current RRSIGs for the DNSKEY RRSET also have a TTL
of 1 day, they're in a situation where they need to do both--add the new
DS record and sign with the old key, in addition to the new key. That
will take care of the situations where either one of the RRSIG or DS
record is cached but not the other. In the case where both are cached,
we'll need to wait until the earliest one's TTL expires from the cache.
Ouch. This is why KSK rollovers need to be done so carefully.
More information about the dns-operations