Confusion about "try-tcp-refresh"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello BIND developers, We have some BIND servers configured as slaves for many hundreds of zones, with the master pointing to our distribution master's IPv4 and IPv6 address. One some of these servers, the IPv6 routing was broken, so that when BIND tried to refresh from the master's IPv6 address, it timed out. Then it tried to refresh over TCP, because the option "try-tcp-refresh" defaults to "yes". This caused even more delays in trying to refresh zones. Eventually they fell back to IPv4, but this caused many zones to lag behind quite often. I've fixed the IPv6 issue now, but then I wanted to set "try-tcp-refresh" to "no" on all these servers, but I'm confused about the location of this setting. The BIND 9.10.2 ARM suggests that it is a per-zone setting. Can I also set it in the global "options" area? Finally, why is this setting defaulting to "yes"? If it's for BIND8 compatibility, isn't it time it defaulted to "no"? Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlU0xdIACgkQi+U8Q0SwlCtvmQCffVXRNn9ey83plPJjoIqHhlTs 4B0Anisoifyruha15LLFRVW/QaiOai30 =N+Oi -END PGP 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: Confusion about "try-tcp-refresh"
Anand Buddhdev wrote: > > The BIND 9.10.2 ARM suggests that it is a per-zone setting. Can I also > set it in the global "options" area? Yes. It is mentioned in the options documentation towards the end of ARM section 6.2.16.1. (A useful thing to know about is doc/misc/options which is automatically generated from the configuration parser source, so check there if you have any doubts about the ARM.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Cromarty, Forth: Variable, mainly west later, 3 or 4. Slight. Fair. Moderate or 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
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
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. 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 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
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 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
