Re: Exercising RFC 5011 rollovers
On Mar 8 2012, I wrote: [...] One experiment I have been doing is to see whether a rollover done as described in https://www.iana.org/dnssec/icann-dps.txt (which is only approximately RFC 5011-like) would cause BIND's managed-keys to do the hoped-for thing or not. That isn't complete yet - I will report on the results in due course. The answer is (as one might expect) that it only approximately does the hoped-for thing ... :-) Refer to Figure 2 in section 6.6 of the IANA document. Assume one starts off with a managed-keys entry for KSK(n) and that there are no compromised keys. During time slots 2-6 (a 50-day period) KSK(n) and KSK(n+1) are published, signed with KSK(n). BIND starts the 30-day add hold-down time for KSK(n+1) the first time it sees this, and after that trusts both KSKs. [If the BIND instance has been offline for a while and its 30 days has not yet elapsed by the end of slot 6, BIND will not yet trust KSK(n+1) and SERVFAILs result thereafter. But only until the BIND instance is restarted, because of the bug(?) I described in the previous posting.] During time slot 7, KSK(n) and KSK(n+1) are published signed with KSK(n+1), and BIND is happy with that. During time slot 8, KSK(n) is published as revoked, but the keyset is signed only by KSK(n+1). BIND doesn't like that, reporting general: warning: managed-keys-zone ./IN: Active key for zone '[test-zone]' is revoked but did not self-sign; ignoring. From time slot 9 onwards, KSK(n) is removed from the published keyset. As BIND still has both KSK(n) and KSK(n+1) as valid trust anchors, never properly revoked, it unhappily keeps reporting that KSK(n) has unexpectedly disappeared. I cannot fault BIND's implementation of RFC 5011 here. The end result is half-satisfactory in that BIND now trusts the new KSK(n+1) and is validating successfully. But it also still trusts KSK(n), and complains about its absence, until one intervenes manually. Which, incidentally, isn't particularly easy to do except by e.g. stopping the BIND instance, editing its managed-keys.bind file to remove the noxious entry, and then restarting it. -- 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
Re: Exercising RFC 5011 rollovers
Continuing a thread from November January (these experiments do take a long time, absent a fake clock)... One experiment I have been doing is to see whether a rollover done as described in https://www.iana.org/dnssec/icann-dps.txt (which is only approximately RFC 5011-like) would cause BIND's managed-keys to do the hoped-for thing or not. That isn't complete yet - I will report on the results in due course. However, I have found one oddity/bug/whatever. I had one testing BIND instance offline for a while so that it had not yet seen new-KSK for 30 days when the test zone transitioned from (old-KSK,new-KSK,ZSK)-signed-with-old-KSK to (old-KSK,new-KSK,ZSK)-signed-with-new-KSK At that point it correctly started giving SERVFAILs for the test zone. However, the entry in managed-keys.bind for new-KSK kept the same (time-first-seen)+30days value for when it was going to start trusting it. Even when this time arrived, it didn't start trusting new-KSK, as I think BIND was acting on this from the RFC Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. (Emphasis on next time and validated!) But now I restarted the BIND instance. It sees in managed-keys.bind that the time it was going to start trusting new-KSK has passed, so it thinks it must be OK now. It adds it to the trust anchors (e.g. as seen by rndc secroots) and the SERVFAILs no longer occur. I think this may indicate that the data structure in managed-keys.bind cannot quite capture all the complexities of RFC 5011. The BIND version used in the later part of this experiment was (early-access) 9.8.2rc2 but I doubt that is particularly significant. -- 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
Re: Exercising RFC 5011 rollovers
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
Re: Exercising RFC 5011 rollovers
On Mon, Jan 09, 2012 at 09:40:51PM +, Chris Thompson wrote: | 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. You have a point. I don't remember making that particular design decision, but I probably just didn't think about it. Reset the acceptance timer implies the existence of a timer; if I'd deleted the key, there wouldn't be a timer to reset. :) Feel free to open a ticket at bind9-b...@isc.org. It's not likely to be a particularly high-priority fix, though. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
Re: Exercising RFC 5011 rollovers
On 11/25/2011 08:49 PM, Evan Hunt wrote: Timing considerations make it difficult to have an automatic test for this in the standard BIND test suite; the RFC requires certain things to take a very long time. Unless you modify named to speed Feature suggestion: some sort of synthetic clock option to named for use in the test suite (--test-unixtime-offset) or something? Obviously non-trivial. ___ 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
Re: Exercising RFC 5011 rollovers
Feature suggestion: some sort of synthetic clock option to named for use in the test suite (--test-unixtime-offset) or something? Obviously non-trivial. Indeed. I think Chris' Evan's suggestion of a public zone that revokes and replaces trust anchors periodically (every few hours?) is better suited to testing. -JP ___ 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
Re: Exercising RFC 5011 rollovers
On 11/26/2011 12:21 PM, Jan-Piet Mens wrote: Feature suggestion: some sort of synthetic clock option to named for use in the test suite (--test-unixtime-offset) or something? Obviously non-trivial. Indeed. I think Chris' Evan's suggestion of a public zone that revokes and replaces trust anchors periodically (every few hours?) is better suited to testing. Wasn't the point of Evan's mail that you can't roll over every few hours? That: the RFC requires certain things to take a very long time ...and: rolling to a new trust anchor and deleting the old one takes over a month ? Certainly a test zone is a good idea, but unless you create lots of them with staggered rollovers, you'll have quite a lag before you see a problem e.g. in a new version of bind. Though I guess there no particular difficulty in creating a lot of them. The synthetic clock approach is used in other large applications and framework test suites to simulate long time windows, and will tell you in seconds rather than hours or days. Maybe something to consider in bind 10. Cheers, Phil ___ 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
Re: Exercising RFC 5011 rollovers
Hi there, On Sat, 26 Nov 2011 Phil Mayers wrote: Feature suggestion: some sort of synthetic clock option ... They say there's a thin line between genius and insanity. Did you just cross it? -- 73, Ged. ___ 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
Re: Exercising RFC 5011 rollovers
On 11/26/2011 01:13 PM, G.W. Haywood wrote: Hi there, On Sat, 26 Nov 2011 Phil Mayers wrote: Feature suggestion: some sort of synthetic clock option ... They say there's a thin line between genius and insanity. Did you just cross it? Thanks for the compliment! But I can't take credit for the idea - as per my other email, this is actually a reasonably common technique for unit-testing, particularly in event-driven systems. Just google fake clock unit test. ___ 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
RE: Exercising RFC 5011 rollovers
There are tools for this. E.g. libfaketime - This communication may not represent my employer's views, if any, on the matters discussed. -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Saturday, November 26, 2011 04:20 To: bind-users@lists.isc.org Subject: Re: Exercising RFC 5011 rollovers On 11/25/2011 08:49 PM, Evan Hunt wrote: Timing considerations make it difficult to have an automatic test for this in the standard BIND test suite; the RFC requires certain things to take a very long time. Unless you modify named to speed Feature suggestion: some sort of synthetic clock option to named for use in the test suite (--test-unixtime-offset) or something? Obviously non-trivial. ___ 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
RE: Exercising RFC 5011 rollovers
There are tools for this. E.g. libfaketime Looks like libfaketime (http://www.code-wizards.com/projects/libfaketime/) lets you accelerate the system time. Adapting one of their examples: LD_PRELOAD=./libfaketime.so.1 FAKETIME=x5000 /bin/bash -c 'while true; do echo $SECONDS ; sleep 43200 ; done'. This should make time pass at a rate of one day every 17 seconds and a month in 9 minutes. ___ 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
Re: Exercising RFC 5011 rollovers
given that their respective administrators have declared an intention to follow RFC 5011 if they ever roll over their KSKs. As you say if they ever roll; I'm not placing any money on that. ;-) I could of course set up such a test zone and try to perform an RFC 5011 rollover on it, using dnssec-revoke and/or the -R option of dnssec-settime, meanwhile tracking it on another system via a managed-keys entry, but then if it all went pear-shaped it might not be clear whether I had performed the rollover correctly or not. I would gladly participate in such a test, if you need me. -JP ___ 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
RE: Exercising RFC 5011 rollovers
Does anyone provide a zone with a trust anchor that is frequently rolled over in that way, just so that one can see whether it really works? Then one's feelings might be warmer and less fuzzy... I looked at the DNSSEC section of the bind test suite (bind-9.9.0b2/bin/tests/system/dnssec) to see if a key rollover test is part of it. I didn't see that, but it may be elsewhere, as the test suite is pretty elaborate. The test suite does contain a simulated root server (ns1), so I bet that with a little ingenuity you could devise a key rollover test. ___ 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
Re: Exercising RFC 5011 rollovers
I looked at the DNSSEC section of the bind test suite (bind-9.9.0b2/bin/tests/system/dnssec) to see if a key rollover test is part of it. I didn't see that, but it may be elsewhere, as the test suite is pretty elaborate. The test suite does contain a simulated root server (ns1), so I bet that with a little ingenuity you could devise a key rollover test. Timing considerations make it difficult to have an automatic test for this in the standard BIND test suite; the RFC requires certain things to take a very long time. Unless you modify named to speed up the process, rolling to a new trust anchor and deleting the old one takes over a month, which is kind of a drag when you're running 'make check'. :) I quite like the idea of setting up a public zone that revokes and replaces trust anchors periodically. I don't know of one at present. The right place to ask is probably the dnssec-deployment mailing list. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
