Question about cache reload

[Lawrence K. Chen, P.Eng.]

----- Original Message -----
> I have just set up DNSSEC on bind 9.9.3.  I had set up the zone and
> put a DS record out at the registrar.  Several days later I found
> that I had set up the keys incorrectly using only NSEC verses NSEC3
> so i changed the keys.  I deleted the old keys and DS record, and
> had bind resign everything and put out the new DS record.  I used
> some testing sites and things looked good.  I then got a message
> from an administrator at a remote site running bind in strict mode
> stating my DNSSEC was broken.  It turns out he had cached the old
> info and it had not updated.  From this I am guessing that bind does
> not flush cache if there is a problem like this, it just fails to
> resolve.
> 
> The other question I am attempting to research is what is the best
> way to do the yearly rekeying and updating of the DS records at the
> registrar to avoid this in the future.
> 

Maybe in preparation for the change, lower the validity period to reduce cache lifetimes.  Not sure if the full procedure for Emergency Key Rollover would work in this case.

Since there's something about mixing algorithms?  Because I had problems when I was switching from RSASHA1-NSEC3-SHA1 to RSASHA256... which is odd, because the registrar had apparently done it....or maybe they had problems that they didn't pass along...though I didn't follow their scheme as closely (partly because I lack the ability to instantly update my DS records.)

... EDUCAUSE is in the process of transitioning the DNSSEC signature
... for the .edu zone from RSA-NSEC3-SHA1 (algorithm 7) to
... RSA/SHA-256 (algorithm 8). Here are the steps that will occur:
... 
...... The algorithm rollover will begin with pre-signing records
...... with new ZSK key, using the RSA/SHA-256 algorithm. This
...... period is expected to begin on November 19, 2011 and will
...... last for nine days.
...... 
...... The pre-signing period will be immediately followed by the
...... publication of the DNSKEY records for the new KSK and ZSK
...... keys in the .edu zone. Once resolvers have the new KSK’s
...... DNSKEY record cached, the DS record for the new KSK will
...... be published in the root zone and the previous DS record
...... will be removed.
...... 
...... The records in the .edu zone will be signed with both
...... old and new algorithms with both ZSK and KSK keys for a
...... period of 14 days. After this period, the old ZSK and the
...... old KSK will have their DNSKEY records removed from the
...... .edu zone. The old ZSK will continue signing for three
...... more days to allow time for all caching resolvers to have
...... purged the old ZSK’s DNSKEY record from their caches.
......
...... Immediately following this three-day period, the rollover
...... will conclude with a period when the signatures with the
...... old ZSK will be systematically and gradually removed
...... from the .edu zone. This period is expected to last
...... between four and seven days.

Lawrence