Exercising RFC 5011 rollovers

[Chris Thompson]

Back in November, I started a thread about testing BIND's managed-keys
code for tracking trust anchor rollovers. Since then I have been doing
some experiments which, as pointed out then, can take quite some time
due to the 30-day "hold-down" times specified in RFC 5011.

Recently I thought I had discovered my first bug in this area, but I have
since downgraded it to an infelicity, and maybe even that is putting it
too strongly. I wonder what others think.

If a new DNSKEY-with-SEP record is published, and fairly soon after
removed (without ever appearing as revoked), RFC 5011 specifies

| If the resolver ever sees the DNSKEY RRSet without the new key but
| validly signed, it stops the acceptance process for that key and
| resets the acceptance timer.

What BIND does is to retain the entry for the new key in managed-keys.bind
but every time it notices that it is no longer published it sets the
KEYDATA.addhd field 30 days in the future. Thus it will never get accepted
as a trust anchor.

That seems to satisfy the letter of the law, but it does mean that
managed-keys.bind remains cluttered with such keys. Would it not be
better for it simply to drop the entry whenever is sees a (properly
signed) DNSKEY RRSet without the key, if the KEYDATA.addhd time has
not yet been reached? If the key subsequently re-appeared, it would
get added again, with the 30-day hold-down period started again, which
seems equally compatible with RFC 5011.

I might add that I hadn't really meant to perform this experiment
at this time... it happened as a result of specifying a set of key
publication and activation times in January 2011 when January 2012
was intended :-)

-- 
Chris Thompson
Email: cet1 at cam.ac.uk