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
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" 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
On Tue, Apr 21, 2015 at 9:55 AM, Edward Lewis wrote: > On 4/21/15, 9:45, "Tony Finch" 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
Edward Lewis 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.finchhttp://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 4/21/15, 9:45, "Tony Finch" 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
Edward Lewis 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.finchhttp://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
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" 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
On Mon, Apr 20, 2015 at 4:33 PM, Evan Hunt wrote: > On Mon, Apr 20, 2015 at 04:17:57PM -0400, Warren Kumari wrote: >> That page says (for BIND): >> "Note: When using this config file you will probably need to delete >> /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys* >> every time you restart BIND after missing a keyroll." (I'm not quite >> sure how that filename was derived...) > > The misguided idea was to make a filename that would be unique for > each view, but not to use the view name because those can contain > characters that are illegal in file names (e.g., '/'). So it's a > sha256 hash of the view name, Cool! It looked like a hash of , I was just too lazy to go figure out what the was. I was hoping it was a hash of something funny... > which is guaranteed to be a legal file > name because it's all hexadecimal. It's also guaranteed to be maximally > confusing. > > As of BIND 9.10, it doesn't name files that way anymore. Awww... Now that I know the secret you've gone and changed it. W > It'll still > read an existing file using that naming format if it finds one, though. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. -- 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 Mon, Apr 20, 2015 at 04:17:57PM -0400, Warren Kumari wrote: > That page says (for BIND): > "Note: When using this config file you will probably need to delete > /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys* > every time you restart BIND after missing a keyroll." (I'm not quite > sure how that filename was derived...) The misguided idea was to make a filename that would be unique for each view, but not to use the view name because those can contain characters that are illegal in file names (e.g., '/'). So it's a sha256 hash of the view name, which is guaranteed to be a legal file name because it's all hexadecimal. It's also guaranteed to be maximally confusing. As of BIND 9.10, it doesn't name files that way anymore. It'll still read an existing file using that naming format if it finds one, 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: Testing RFC 5011 key roll
On Mon, Apr 20, 2015 at 3:41 PM, Edward Lewis wrote: > Thanks. rm'd the file and added the timers. (I did that also after > sending, so it is the deleting the old file that did the trick.) The > start-up lines look good. > > Got an AD bit again too. > > (I may have a few more issues as I move this off a laptop on to a regular > machine. Right now it helps knowing where the loose bits are stored.) Just FYI, the "current" key should always be at: http://keyroll.systems/current , along with pre-built named.conf and unbound.conf, suitable for cutting and pasting into config files. That page says (for BIND): "Note: When using this config file you will probably need to delete /var/named/21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys* every time you restart BIND after missing a keyroll." (I'm not quite sure how that filename was derived...) Jakob Schlyter created a nifty toolset at https://github.com/jschlyter/keyroll/ to download the key, put it in the right format, etc. It comes with config files for Unbound and BIND, and makes using this simpler and easier! > > On 4/20/15, 15:12, "Evan Hunt" 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. Actually it seems to be every 90 minutes at the moment. keyroll.systems is very much a kludge W >> >>-- >>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 -- 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
Thanks. rm'd the file and added the timers. (I did that also after sending, so it is the deleting the old file that did the trick.) The start-up lines look good. Got an AD bit again too. (I may have a few more issues as I move this off a laptop on to a regular machine. Right now it helps knowing where the loose bits are stored.) On 4/20/15, 15:12, "Evan Hunt" 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
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. ___ 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
Thanks to Evan for the last look and thanks to Jan-Piet for the suggestion
to go to 9.10.2.
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.
I've built and installed BIND 9.10.2. Using http://keyroll.systems,
there's a page showing the BIND config and it seems to have the current
key there. (I thought the page was static.) I guess I'm just a bit
surprised, anyway, I have that key in place.
And - I've also updated by unbound, I do get an 'ad' bit for "./IN/SOA".
(I need to figure out why I needed to update unbound - perhaps it is that
I'm on a laptop and not a 24x7 machine, but I can get it to validate.)
Ugly details below:
This time I do see an error upon startup:
$ named -g -c rfc5011.conf
20-Apr-2015 14:34:18.432 starting BIND 9.10.2 -g -c rfc5011.conf
20-Apr-2015 14:34:18.432 built with '--with-openssl=/usr/local/ssl'
'STD_CDEFINES=-DDIG_SIGCHASE=1'
20-Apr-2015 14:34:18.432
20-Apr-2015 14:34:18.432 BIND 9 is maintained by Internet Systems
Consortium,
20-Apr-2015 14:34:18.432 Inc. (ISC), a non-profit 501(c)(3) public-benefit
20-Apr-2015 14:34:18.432 corporation. Support and training for BIND 9 are
20-Apr-2015 14:34:18.432 available at https://www.isc.org/support
20-Apr-2015 14:34:18.432
20-Apr-2015 14:34:18.432 found 4 CPUs, using 4 worker threads
20-Apr-2015 14:34:18.432 using 2 UDP listeners per interface
20-Apr-2015 14:34:18.433 using up to 4096 sockets
20-Apr-2015 14:34:18.439 loading configuration from
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf'
20-Apr-2015 14:34:18.439 reading built-in trusted keys from file
'/etc/bind.keys'
20-Apr-2015 14:34:18.439 using default UDP/IPv4 port range: [49152, 65535]
20-Apr-2015 14:34:18.440 using default UDP/IPv6 port range: [49152, 65535]
20-Apr-2015 14:34:18.440 listening on IPv6 interface lo0, ::1#1053
20-Apr-2015 14:34:18.442 listening on IPv4 interface lo0, 127.0.0.1#1053
20-Apr-2015 14:34:18.442 generating session key for dynamic DNS
20-Apr-2015 14:34:18.443 sizing zone task pool based on 1 zones
20-Apr-2015 14:34:18.445 set up managed keys zone for view recursive, file
'21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys'
20-Apr-2015 14:34:18.445 automatic empty zone: view recursive:
10.IN-ADDR.ARPA...yadda...yadda...yadda...
20-Apr-2015 14:34:18.449 command channel listening on 127.0.0.1#1953
20-Apr-2015 14:34:18.449 not using config file logging statement for
logging due to -g option
20-Apr-2015 14:34:18.449 managed-keys-zone/recursive: loaded serial 3
20-Apr-2015 14:34:18.460 all zones loaded
20-Apr-2015 14:34:18.460 running
20-Apr-2015 14:34:18.554 validating ./DNSKEY: unable to find a DNSKEY
which verifies the DNSKEY RRset and also matches a trusted key for '.'
20-Apr-2015 14:34:18.554 no valid KEY resolving './DNSKEY/IN':
204.42.252.20#53
20-Apr-2015 14:34:18.554 broken trust chain resolving './NS/IN':
204.42.252.20#53
My rfc5011.conf file is:
$ cat rfc5011.conf
options
{
dnssec-enable yes;
dnssec-validation yes;
pid-file none;
session-keyfile "session.key";
notify no;
listen-on port 1053 { 127.0.0.1; };
listen-on-v6 port 1053 { ::1; };
};
key "rndc-key"
{
algorithm hmac-md5;
secret "cuxAvCYntho2ia6jhDM4yw==";
};
controls
{
inet 127.0.0.1 port 1953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
managed-keys {
. initial-key 257 3 8
"AwEAAaTCfs92ag0oZpg/uzN7NcN2aIXZxR7Q1XOin8eEei+QPR0dXrI7
DskSUNVBsHMS6piMCTQRqFHq1TwY19tWiJJf0meZWRMWTOrzyFd/Tioa
KwWTga0bNN09dciQmNxJyfnHDNfqJ8k3LeQz8WHQzc9QC0x8cOmT1IG7
yn+0S6QFl4/G6uwBxJ3ejxdiygJQKa8i3YAv3EEKP066YuRki5h1yz93
P9UEyU2E2MOByqMJtgpaBPbOX5riTdaTu5gXKnoJyag//545+Z43+Y6u
+wQzfnFFhWHzQiH8Yl3y4qNuBVXSvlmg9XU4LhT7EqTA+v5v/O2Humkm
KqetoGkEbJ0=";
};
view "recursive" IN {
match-clients { any; };
allow-query { any; };
recursion yes;
allow-recursion { any; };
// prime the server with the RFC5011 Key roll server.
zone "." {
type hint;
file "keyroller-db.root";
};
}; // End of recursive view.
The current dig "fake-. dnskey" is:
$ dig @204.42.252.20 . dnskey
; <<>> DiG 9.10.2 <<>> @204.42.252.20 . dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16270
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 3600IN DNSKEY 385 3 8
AwEAAb1tBF4Fbnx8Wx4dDpoMbeKpId70bZyWRzz07uORb5ZrbgQfy8u1
sFH9k3kNsisc09CoG/aSGIsrEz0OueGHFDbwSWdaIwVFIpNRBwGQjbvf
pzod0HTfSo2Ka7oFBuc7Sm5CSjbxcXJ28FW9BCn/SboI1bw08R322rEy
oA1rwc8tDpyApUXP57fuf
Re: Testing RFC 5011 key roll
Edward, the subject of this message piqued my interest ;-) > 17-Apr-2015 10:17:02.083 starting BIND 9.10.0 -g -c rfc5011.conf Very ouch. Much pain. Lots frustration. Many hairpulls. Mucho crash. ;) Upgrade to 9.10.2 [1] in which Evan fixes the CVE we discovered on RFC5011 rolls and, thankfully, adds comments to BIND's managed-keys.db in which BIND then tells us nice things, e.g. whether key is trusted, revoked, etc. -JP [1] https://kb.isc.org/article/AA-01257/0/BIND-9.10.2-Release-Notes.html ___ 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
Thanks. Now have 'ad' bits via both BIND and unbound. Will let you know when I've shot myself in the foot. On 4/17/15, 12:45, "Evan Hunt" wrote: ... >instead of waiting a full 30 days. (This is, I hope obviously, *not* >something you want to run in production. :) ) 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
On Fri, Apr 17, 2015 at 02:46:16PM +, Edward Lewis wrote: > I am building named and unbound recursive servers to follow a test of RFC > 5011 trust anchor updates, the experiment is documented at > http://keyroll.systems. One reason why I'm asking here is in > http://jpmens.net/2015/01/21/opendnssec-rfc-5011-bind-and-unbound/ > which mentions some issues with RFC 5011 rolls in BIND. I believe all of the issues Jan-Piet discovered have been fixed in the latest versions. > But I bet my problem is that I haven't included yet-another configuration > statement. A minor nit: You have both a bindkeys-file (which is loaded when you use "dnssec-validation auto") and a managed-keys statement in your named.conf. It's harmless, but there's no need to have both. You can lose the bindkeys file and set "dnssec-validation yes", or lose the managed-keys statement. The key at keyroll.systems rolls every 90 minutes if I recall correctly, so when you start the process you'll need to be sure you're using the latest key; if you leave your file alone for a few hours it'll stop working. "dig @204.42.252.20 dnskey ." will show you the current key set. I tried your configuration, and after updating the key to the most recent one, I am getting responses that validate. By the way, if you want to ensure that named smoothly rolls over to the next key, you'll need to adjust its timers. RFC 5011 says that you can't trust a new key until it's been in the DNSKEY rrset for at least a month. To enable testing in a reasonable time, there's an undocumented option to named that redefines time units for RFC 5011 purposes: $ named -T mkeytimers=2/5/60 The numbers between the slashes are the number of seconds to use for an "hour", a "day", and a "month", respectively. If you run with the above option, named will trust a new key 60 seconds after it's seen it, instead of waiting a full 30 days. (This is, I hope obviously, *not* something you want to run in production. :) ) -- 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
Testing RFC 5011 key roll
I am building named and unbound recursive servers to follow a test of RFC
5011 trust anchor updates, the experiment is documented at
http://keyroll.systems. One reason why I'm asking here is in
http://jpmens.net/2015/01/21/opendnssec-rfc-5011-bind-and-unbound/
which mentions some issues with RFC 5011 rolls in BIND.
But I bet my problem is that I haven't included yet-another configuration
statement.
I have unbound working, but can't get bind to give me an 'ad' bit, so I'm
certain that the authoritative server side is set up right.
What is puzzling is that I don't see any (relevant) errors when starting
up my named instance.
I'm running named in user space, off port 1053. So the "permission
denied" parts are acceptable.
$ named -g -c rfc5011.conf
17-Apr-2015 10:17:02.083 starting BIND 9.10.0 -g -c rfc5011.conf
17-Apr-2015 10:17:02.083 built with '--with-openssl=/usr/local/ssl'
'STD_CDEFINES=-DDIG_SIGCHASE=1'
17-Apr-2015 10:17:02.083
17-Apr-2015 10:17:02.083 BIND 9 is maintained by Internet Systems
Consortium,
17-Apr-2015 10:17:02.083 Inc. (ISC), a non-profit 501(c)(3) public-benefit
17-Apr-2015 10:17:02.083 corporation. Support and training for BIND 9 are
17-Apr-2015 10:17:02.083 available at https://www.isc.org/support
17-Apr-2015 10:17:02.083
17-Apr-2015 10:17:02.083 found 4 CPUs, using 4 worker threads
17-Apr-2015 10:17:02.083 using 2 UDP listeners per interface
17-Apr-2015 10:17:02.084 using up to 4096 sockets
17-Apr-2015 10:17:02.091 loading configuration from
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf'
17-Apr-2015 10:17:02.092 reading built-in trusted keys from file
'/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key'
17-Apr-2015 10:17:02.092 using default UDP/IPv4 port range: [49152, 65535]
17-Apr-2015 10:17:02.092 using default UDP/IPv6 port range: [49152, 65535]
17-Apr-2015 10:17:02.093 listening on IPv6 interfaces, port 53
17-Apr-2015 10:17:02.093 could not listen on UDP socket: permission denied
17-Apr-2015 10:17:02.093 listening on all IPv6 interfaces failed
17-Apr-2015 10:17:02.093 listening on IPv4 interface lo0, 127.0.0.1#1053
17-Apr-2015 10:17:02.094 generating session key for dynamic DNS
17-Apr-2015 10:17:02.094 couldn't mkdir '/var/run/named': Permission denied
17-Apr-2015 10:17:02.094 could not create /var/run/named/session.key
17-Apr-2015 10:17:02.094 failed to generate session key for dynamic DNS:
permission denied
17-Apr-2015 10:17:02.094 sizing zone task pool based on 1 zones
17-Apr-2015 10:17:02.096 using built-in root key for view recursive
17-Apr-2015 10:17:02.097 set up managed keys zone for view recursive, file
'21ce078705d04ca6324c1d0313fc08ea99f3cef6389a6744d40bd2d9d0cd7816.mkeys'
17-Apr-2015 10:17:02.097 automatic empty zone: ...yadda...yadda...yadda...
17-Apr-2015 10:17:02.101 command channel listening on 127.0.0.1#1953
17-Apr-2015 10:17:02.101 not using config file logging statement for
logging due to -g option
17-Apr-2015 10:17:02.101 listening on IPv6 interfaces, port 53
17-Apr-2015 10:17:02.101 could not listen on UDP socket: permission denied
17-Apr-2015 10:17:02.101 listening on all IPv6 interfaces failed
17-Apr-2015 10:17:02.101 managed-keys-zone/recursive: loaded serial 5
17-Apr-2015 10:17:02.112 all zones loaded
17-Apr-2015 10:17:02.112 running
$ cat /Users/edwardlewis/Documents/DNS/secure_BIND_resolver/rfc5011.conf
options
{
dnssec-enable yes;
dnssec-validation auto;
bindkeys-file
"/Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key";
pid-file none;
dump-file "5011logs/cache_dump.db";
statistics-file "5011logs/named_stats.txt";
memstatistics-file "5011logs/named.memstats";
zone-statistics yes;
hostname "foobar";
recursion yes;
notify no;
auth-nxdomain no;
listen-on port 1053 { 127.0.0.1; };
};
managed-keys {
.initial-key 257 3 8
"AwEAAchoK9nG+mBjR/NZKqez+XYcqoWPL5e0VTreHS3Wi1KmU0Qgsr1N3O9u+McnsUwF/dsSW8
F/h3yXSMAEhS731eFvqxNDkhL8rQUfGBtALB3onTthYM38fk16vki5UsCecbt3uI46lb5cz5Dts
9drW/55OckwnSw4GTwiq2zebO5fo/UZlftpZTsupqgojL1Y3QlqL0LpP+vPIAgBe+OfhVpFPLxT
P6aeKoNviWC0O2CJiVqVZxp9cumjwOnKUvSfHcsl8tcH3cQjmIhQDDw+Z109J9ly+QcL6RUdHo9
m/TyKL04dQulKBAmgWanAQ0CF7zwhIiUxkxTsUtMTRMuXWcM=";
};
view "recursive" IN {
match-clients { any; };
allow-query { any; };
recursion yes;
allow-recursion { any; };
// prime the server with the RFC5011 Key roll server.
zone "." {
type hint;
file "keyroller-db.root";
};
}; // End of recursive view.
$ cat /Users/edwardlewis/Documents/DNS/secure_BIND_resolver/test.key
managed-keys {
. initial-key 257 3 8
"AwEAAchoK9nG+mBjR/NZKqez+XYcqoWPL5e0VTreHS3Wi1KmU0Qgsr1N3O9u+McnsUwF/dsSW8
F/h3yXSMAEhS731eFvqxNDkhL8rQUfGBtALB3onTthYM38fk16vki5UsCecbt3uI46lb5cz5Dts
9drW/55OckwnSw4GTwiq2zebO5fo/UZlftpZTsupqgojL1Y3QlqL0LpP+vPIA
