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 wil
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 m
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
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 d
> 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 ;
urday, 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
>
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
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/mailma
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 a
> 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?) i
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 opti
> 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
> 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
> 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, usi
Using "managed-keys" for the root zone and for dlv.isc.org can give one
a warm fuzzy feeling, given that their respective administrators have
declared an intention to follow RFC 5011 if they ever roll over their
KSKs.
Except, they never have changed their KSKs so far, so the relevant code
in BIND
15 matches
Mail list logo