Re: Testing RFC 5011 key roll
Evan/et.al., I've updated to 9.10.2, adjusted the timers, etc., and have managed to follow the keyroll.systems test over night (a handful of key changes) plus still get the desired AD bit. With the timing in mind, I looked at my unbound (I realize this is BIND users ;)) which wasn't keeping up with the rolls - I had neglected to speed up it's clock. Once I did that, it worked. My lesson is - besides just working out the configuration - testing RFC5011 takes more patience than just about any other feature of DNS/DNSSEC. RFC5011 is the most wall-clock driven mechanism we have. (Yes, signatures expire and TTL's lapse, but these can be set low in lab environments.) I have a suggestion - is there a way to query a BIND server for it's trust anchor key set? Perhaps it is unnecessary and perhaps it should only be allowed by authorized users. I say perhaps unnecessary because the information may be available on disk (which an administrator could get to via ssh, perhaps). Ed On 4/20/15, 15:12, Evan Hunt e...@isc.org wrote: On Mon, Apr 20, 2015 at 06:42:42PM +, Edward Lewis wrote: Being that I'm working on a laptop (hence on on over the weekend) I've had to recreate the environment today. I'm a bit more puzzled now. There's a separate file that named creates to keep the current managed keys state information -- it's based on the view name, so in your case it'll be recursive.mkeys (and possibly recursive.mkeys.jnl). I suspect it still has the key from Friday in it, and that's messing things up. Delete that file and reinitialize, then leave the server up and running (not forgetting to use -T mkeytimers=H/D/M, where M is no more than 3600 seconds, because keyroll.systems rolls its keys every hour and normal RFC 5011 processing can't handle that), and you should be in good shape. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. smime.p7s Description: S/MIME cryptographic signature ___ 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: Testing RFC 5011 key roll
By default it dumps its output to a file; you can use `rndc secroots -` to get output on stdout. Using - to get it to dump the secroots output to stdout is a new feature added for 9.11. That hasn't been published yet, but if you build from the source tree at source.isc.org (like Tony does), you can it. If you're doing that, then you can *also* use rndc managed-keys, which lets you check key status and force keys to be refreshed ahead of schedule. -- 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: Testing RFC 5011 key roll
On 4/21/15, 10:15, Warren Kumari war...@kumari.net wrote: From the ARM: Sigh, RTFM...(My, BIND's gotten a lot more complicated/feature-rich since I last read the docs.) Hey, it's there. smime.p7s Description: S/MIME cryptographic signature ___ 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: Testing RFC 5011 key roll
Edward Lewis edward.le...@icann.org wrote: I have a suggestion - is there a way to query a BIND server for it's trust anchor key set? rndc secroots (though this only provides the key tags not the public key data) I say perhaps unnecessary because the information may be available on disk (which an administrator could get to via ssh, perhaps). You can also look in the .mkeys file. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: In southeast, cyclonic 5 to 7, but easterly 6 to gale 8 in far southeast. In northwest, variable 4, becoming southwesterly 4 or 5 in west later. In southeast, moderate or rough. in northwest, mainly moderate. In southeast, occasional rain. In northwest, showers. In southeast, moderate or good. In northwest, good. ___ 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: Testing RFC 5011 key roll
Edward Lewis edward.le...@icann.org wrote: I tried secroots with my set up, I got nothing despite the mkeys file. (Kind of asking - does that work?): By default it dumps its output to a file; you can use `rndc secroots -` to get output on stdout. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides, Bailey: Southwesterly 4 or 5, increasing 6 or 7 in north Bailey. Moderate, becoming rough in north Bailey. Occasional drizzle, fog patches. Moderate or good, occasionally very poor. ___ 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: Testing RFC 5011 key roll
On Tue, Apr 21, 2015 at 9:55 AM, Edward Lewis edward.le...@icann.org wrote: On 4/21/15, 9:45, Tony Finch d...@dotat.at wrote: rndc secroots You can also look in the .mkeys file. I tried secroots with my set up, I got nothing despite the mkeys file. (Kind of asking - does that work?): (I had my rndc port bumped out of sudo-land, so it's overridden:) $ rndc -p 1953 -c rndc.conf secroots From the ARM: secroots-file: The pathname of the file the server dumps security roots to when instructed to do so with rndc secroots. If not specified, the default is named.secroots. root@eric:/var/named# rndc secroots root@eric:/var/named# more named.secroots 21-Apr-2015 10:07:02.278 Start view external ./RSASHA256/19036 ; managed dlv.isc.org/RSASHA1/19297 ; trusted W $ $ cat 21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys $ORIGIN . $TTL 0 ; 0 seconds @ IN SOA . . ( 879; serial 0 ; refresh (0 seconds) 0 ; retry (0 seconds) 0 ; expire (0 seconds) 0 ; minimum (0 seconds) ) KEYDATA 20150421135415 20150421125042 1970010100 257 3 8 ( AwEAAb7pfymUZ3LzR7ldtJ5fvgxxu/Y4I7QtBmlqlhJS Je6Ugw+/72eYAnLYh7xHaNkAzjP6oi1rxOL0s9wj7TVU +r9bK+KuzOvZfKzNS+ywTdZ0QXSJSJNTLJfgaMMvnyp/ K2LajQ4wNV1UblSqPPs9FdCXqVbxKF7i4j6h6QO61xkf s2LSkiPu+TCK05fizdfuDIit8KlQr6sgV1jiBrXm4kmY 5o9txePRz8oy/C4+6IDVtA1zSlDTvsbwYk1KjHa9CXcA 7BkuYaBlxB4zgBF/koaX55IdhbKKkwsN8qJhPanu72zq 2933IF96RtikjvX/ugC7VBvNlGgy5dQrvKu/G7M= ) ; KSK; alg = RSASHA256; key id = 26512 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT ; trusted since: Tue, 21 Apr 2015 12:50:42 GMT KEYDATA 20150421135415 20150421135145 1970010100 257 3 8 ( AwEAAeHrxs5uJwldPTjAplgBzGRptPYrFgNFoPZDyrEa CAuNckUuHkQIMr5Pkv/XONS2CLcLmq5HtvLPzevkAjWv wIMhYn0nE4fTTl8diTnOFKLEcPBs/jAqKU5n/ZV5ZXiP NCUgg3qvXetntojb+JesE9fdYgUlWrgIUjx9y17Fhb+J lP56kqhxER2L0AUEFTH+x/Jxkzea6E8FFkYGUJ+tzEt0 S+ESRaDTNmdKgqe9GAi6ID3GRYgsn9cgNIOmBYHrzhQv R5XaTK37nUlVMKjyQxu2Lq+lhIu9348aSt+g42QJxJ1s VTRPVPEVQt1s71SHuWTd/OBCz5f8fZqQrG0mA9E= ) ; KSK; alg = RSASHA256; key id = 8869 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT ; trusted since: Tue, 21 Apr 2015 13:51:45 GMT ___ 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: Testing RFC 5011 key roll
On 4/21/15, 9:45, Tony Finch d...@dotat.at wrote: rndc secroots You can also look in the .mkeys file. I tried secroots with my set up, I got nothing despite the mkeys file. (Kind of asking - does that work?): (I had my rndc port bumped out of sudo-land, so it's overridden:) $ rndc -p 1953 -c rndc.conf secroots $ $ cat 21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys $ORIGIN . $TTL 0 ; 0 seconds @ IN SOA . . ( 879; serial 0 ; refresh (0 seconds) 0 ; retry (0 seconds) 0 ; expire (0 seconds) 0 ; minimum (0 seconds) ) KEYDATA 20150421135415 20150421125042 1970010100 257 3 8 ( AwEAAb7pfymUZ3LzR7ldtJ5fvgxxu/Y4I7QtBmlqlhJS Je6Ugw+/72eYAnLYh7xHaNkAzjP6oi1rxOL0s9wj7TVU +r9bK+KuzOvZfKzNS+ywTdZ0QXSJSJNTLJfgaMMvnyp/ K2LajQ4wNV1UblSqPPs9FdCXqVbxKF7i4j6h6QO61xkf s2LSkiPu+TCK05fizdfuDIit8KlQr6sgV1jiBrXm4kmY 5o9txePRz8oy/C4+6IDVtA1zSlDTvsbwYk1KjHa9CXcA 7BkuYaBlxB4zgBF/koaX55IdhbKKkwsN8qJhPanu72zq 2933IF96RtikjvX/ugC7VBvNlGgy5dQrvKu/G7M= ) ; KSK; alg = RSASHA256; key id = 26512 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT ; trusted since: Tue, 21 Apr 2015 12:50:42 GMT KEYDATA 20150421135415 20150421135145 1970010100 257 3 8 ( AwEAAeHrxs5uJwldPTjAplgBzGRptPYrFgNFoPZDyrEa CAuNckUuHkQIMr5Pkv/XONS2CLcLmq5HtvLPzevkAjWv wIMhYn0nE4fTTl8diTnOFKLEcPBs/jAqKU5n/ZV5ZXiP NCUgg3qvXetntojb+JesE9fdYgUlWrgIUjx9y17Fhb+J lP56kqhxER2L0AUEFTH+x/Jxkzea6E8FFkYGUJ+tzEt0 S+ESRaDTNmdKgqe9GAi6ID3GRYgsn9cgNIOmBYHrzhQv R5XaTK37nUlVMKjyQxu2Lq+lhIu9348aSt+g42QJxJ1s VTRPVPEVQt1s71SHuWTd/OBCz5f8fZqQrG0mA9E= ) ; KSK; alg = RSASHA256; key id = 8869 ; next refresh: Tue, 21 Apr 2015 13:54:15 GMT ; trusted since: Tue, 21 Apr 2015 13:51:45 GMT smime.p7s Description: S/MIME cryptographic signature ___ 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: Testing RFC 5011 key roll
My lesson is - besides just working out the configuration - testing RFC5011 takes more patience than just about any other feature of DNS/DNSSEC. RFC5011 is the most wall-clock driven mechanism we have. Yup. I learned that as well. As a side note: can you imagine my surprise when, after waiting all that time BIND then crashed on me after being fed OpenDNSSEC keys? Had to start all over and explain excessive hair loss to the missus ... It's thanks to Warren's keyroll.systems that I actually persisted testing, and only then did I report the crash to ISC, whereupon I was forced to wait a full rollover period until I was allowed to talk about it. ;-) -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
