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: c...@cam.ac.uk _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users