RE: Slow recursive query performance on Windows x64
... And please don't misunderstand; I'm not asking you to debug my network.
There are actually two parts here, one is what the clients are/n't doing with
the responses they receive, and that's sort of beside the point and came
up incidentally, They aren't really experiencing any issues or problems just
from the fact that they get responses; it was mostly just wishful thinking
in the sense of "why give them responses they don't need and can't ever use?"
No machines on this network have IPv6 default routes in their routing tables.
I'm not trying to argue with you or make a stink about it. Hopefully I didn't
come across that way.
But setting that aside, on the BIND server itself, IPv6 is not bound on any NIC
(only the built-in Windows ISATAP adapter which is unsupported to disable), and
the IPv6 routing table does not contain any routes at all except for ::1/128
and ff00::/8 - so that's why it was puzzling to me that it BIND would still
try to use IPv6 for outbound queries, especially when started with the -4 flag.
The response you get back from trying to ping any (ipv6) host in an unreachable
network in this situation (on a Windows kernel) is not an ICMP Unreachable, but
rather a "Transmit Failed: General Failure" which doesn't show up anywhere in a
packet trace, even on the loopback adapter. If BIND is looking for the ICMP
message specifically to decide whether IPv6 is go or no-go, perhaps it's not
perceiving that General Failure means "don't keep trying this, it will never
work" so it's still waiting for the timeout. I'm not saying you have to chase
this down, just pointing out that this seems (to me) to be unexpected behavior
on a standard-configuration Windows host system in an IPv4-only network.
-Steve
-Original Message-
From: Ondrej Sur�
Sent: Monday, January 20, 2020 9:37 AM
To: Steve Farr
Cc: bind-users@lists.isc.org
Subject: Re: Slow recursive query performance on Windows x64
The problem is that apparently[*] the machines in your network have default
IPv6 routes, but you don t have IPv6 connectivity. Fix that and you don t have
to apply any bandaids. I think we should just remove filter- in the next
release cycle of BIND 9, having the feature doesn t do any good for the health
of the Internet.
* - Normally, the ICMP unreachables are generated by local kernel, and based on
the evidences you provided (timeouts) it doesn t, so something is misconfigured
either in your network or on that particular machine. Debugging your network is
beyond the scope of this mailing list.
Ondrej
--
Ondrej SurISC
> On 20 Jan 2020, at 15:19, Steve Farr via bind-users
> wrote:
>
> ?Yeah, it's hard to disagree on the "should" part but we all definitely have
> to administer networks in an imperfect world... To my mind, when there's zero
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall
> to create 3x more TCP connections that it can never complete, and/or have it
> send unreachables for all of them, especially on a larger network, so I would
> suggest that even if it is "wrong," filter--on-v4 is probably still
> "helpful" in some situations, particularly where v6 is not available. The
> network that I originally posted about is small, but I administer a number of
> larger ones and this has been very eye-opening, so I do thank you all for
> your contributions to the conversation.
>
> It looks like I'd have to compile the filter plugin separately on Windows
> since it's not already integrated, and I don't see a dll or exe for it in the
> bin folder... That's all right though; I'm just glad to have the query times
> be so much quicker now!
>
> In case it's useful for anyone to know, I did just now try running named with
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has
> the same delay problem, so it appears that even with -4 it's still trying to
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes;
> }; is still the fix... at least on Windows, anyway. Many thanks again to all
> of you for the insightful responses.
>
> -Steve
>
> -Original Message-
> From: bind-users On Behalf Of Mark
> Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee
> Cc: Ondrej Sury
> Subject: Re: Slow recursive query performance on Windows x64
>
> Devices should return ICMP unreachables when networks are not reachable.
> This allows applications to move onto the next address. Not returning
> unreachables results in timeouts being the mechanism to move to the next
> address.
>
> Additionally applications can make parallel connection attempts. This works
> particularly well for TCP and is what Happy Eyeballs does with a slight delay
> (sub second) between each diffe
Re: Slow recursive query performance on Windows x64
The problem is that apparently[*] the machines in your network have default
IPv6 routes, but you don’t have IPv6 connectivity. Fix that and you don’t have
to apply any bandaids. I think we should just remove filter- in the next
release cycle of BIND 9, having the feature doesn’t do any good for the health
of the Internet.
* - Normally, the ICMP unreachables are generated by local kernel, and based on
the evidences you provided (timeouts) it doesn’t, so something is misconfigured
either in your network or on that particular machine. Debugging your network is
beyond the scope of this mailing list.
Ondřej
--
Ondřej Surý — ISC
> On 20 Jan 2020, at 15:19, Steve Farr via bind-users
> wrote:
>
> Yeah, it's hard to disagree on the "should" part but we all definitely have
> to administer networks in an imperfect world... To my mind, when there's zero
> ipv6 connectivity beyond the LAN, it would be handy to not ask the firewall
> to create 3x more TCP connections that it can never complete, and/or have it
> send unreachables for all of them, especially on a larger network, so I would
> suggest that even if it is "wrong," filter--on-v4 is probably still
> "helpful" in some situations, particularly where v6 is not available. The
> network that I originally posted about is small, but I administer a number of
> larger ones and this has been very eye-opening, so I do thank you all for
> your contributions to the conversation.
>
> It looks like I'd have to compile the filter plugin separately on Windows
> since it's not already integrated, and I don't see a dll or exe for it in the
> bin folder... That's all right though; I'm just glad to have the query times
> be so much quicker now!
>
> In case it's useful for anyone to know, I did just now try running named with
> the -4 option, taking out the server ::/0 { bogus yes; }; and it still has
> the same delay problem, so it appears that even with -4 it's still trying to
> do something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes;
> }; is still the fix... at least on Windows, anyway. Many thanks again to all
> of you for the insightful responses.
>
> -Steve
>
> -Original Message-
> From: bind-users On Behalf Of Mark Andrews
> Sent: Monday, January 20, 2020 1:45 AM
> To: Lee
> Cc: Ondrej Sury
> Subject: Re: Slow recursive query performance on Windows x64
>
> Devices should return ICMP unreachables when networks are not reachable.
> This allows applications to move onto the next address. Not returning
> unreachables results in timeouts being the mechanism to move to the next
> address.
>
> Additionally applications can make parallel connection attempts. This works
> particularly well for TCP and is what Happy Eyeballs does with a slight delay
> (sub second) between each different address. Once a TCP connection succeeds
> the other connection attempts are aborted. Too many developers have coped
> out on providing fast multi-homing support. It usually only takes small
> while to convert a application from serial connection attempts to parallel
> connection attempts to the addresses returned from getaddrinfo(). What s
> more work is adding MIF (multiple interface) support which allows you to try
> different source addresses as well.
>
> Mark
>
>> On 20 Jan 2020, at 17:16, Lee wrote:
>>
>>> On 1/20/20, Ondrej Sur wrote:
>>>
>>> Please note that filter--on-v4 was always wrong.
>>
>> how so?
>>
>>> You should fix your network instead. It s a bandaid, not a fix.
>>
>> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
>> unless you mean disable ipv6 on everything? (which I'm not sure is
>> even possible)
>>
>> Lee
>> ___
>> 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
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
> ___
> 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
>
>
> ___
> 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
___
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: Slow recursive query performance on Windows x64
Yeah, it's hard to disagree on the "should" part but we all definitely have to
administer networks in an imperfect world... To my mind, when there's zero ipv6
connectivity beyond the LAN, it would be handy to not ask the firewall to
create 3x more TCP connections that it can never complete, and/or have it send
unreachables for all of them, especially on a larger network, so I would
suggest that even if it is "wrong," filter--on-v4 is probably still
"helpful" in some situations, particularly where v6 is not available. The
network that I originally posted about is small, but I administer a number of
larger ones and this has been very eye-opening, so I do thank you all for your
contributions to the conversation.
It looks like I'd have to compile the filter plugin separately on Windows since
it's not already integrated, and I don't see a dll or exe for it in the bin
folder... That's all right though; I'm just glad to have the query times be so
much quicker now!
In case it's useful for anyone to know, I did just now try running named with
the -4 option, taking out the server ::/0 { bogus yes; }; and it still has the
same delay problem, so it appears that even with -4 it's still trying to do
something on v6 that it shouldn't be doing. So, server ::/0 { bogus yes; }; is
still the fix... at least on Windows, anyway. Many thanks again to all of you
for the insightful responses.
-Steve
-Original Message-
From: bind-users On Behalf Of Mark Andrews
Sent: Monday, January 20, 2020 1:45 AM
To: Lee
Cc: Ondrej Sury
Subject: Re: Slow recursive query performance on Windows x64
Devices should return ICMP unreachables when networks are not reachable. This
allows applications to move onto the next address. Not returning unreachables
results in timeouts being the mechanism to move to the next address.
Additionally applications can make parallel connection attempts. This works
particularly well for TCP and is what Happy Eyeballs does with a slight delay
(sub second) between each different address. Once a TCP connection succeeds the
other connection attempts are aborted. Too many developers have coped out on
providing fast multi-homing support. It usually only takes small while to
convert a application from serial connection attempts to parallel connection
attempts to the addresses returned from getaddrinfo(). What s more work is
adding MIF (multiple interface) support which allows you to try different
source addresses as well.
Mark
> On 20 Jan 2020, at 17:16, Lee wrote:
>
> On 1/20/20, Ondrej Sur wrote:
>>
>> Please note that filter--on-v4 was always wrong.
>
> how so?
>
>> You should fix your network instead. It s a bandaid, not a fix.
>
> My ISP doesn't offer ipv6, so I'm not sure how to fix my network..
> unless you mean disable ipv6 on everything? (which I'm not sure is
> even possible)
>
> Lee
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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
___
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: Slow recursive query performance on Windows x64
Devices should return ICMP unreachables when networks are not reachable. This allows applications to move onto the next address. Not returning unreachables results in timeouts being the mechanism to move to the next address. Additionally applications can make parallel connection attempts. This works particularly well for TCP and is what Happy Eyeballs does with a slight delay (sub second) between each different address. Once a TCP connection succeeds the other connection attempts are aborted. Too many developers have coped out on providing fast multi-homing support. It usually only takes small while to convert a application from serial connection attempts to parallel connection attempts to the addresses returned from getaddrinfo(). What’s more work is adding MIF (multiple interface) support which allows you to try different source addresses as well. Mark > On 20 Jan 2020, at 17:16, Lee wrote: > > On 1/20/20, Ondřej Surý wrote: >> >> Please note that filter--on-v4 was always wrong. > > how so? > >> You should fix your network instead. It’s a bandaid, not a fix. > > My ISP doesn't offer ipv6, so I'm not sure how to fix my network.. > unless you mean disable ipv6 on everything? (which I'm not sure is > even possible) > > Lee > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Slow recursive query performance on Windows x64
On 1/20/20, Ondřej Surý wrote: > > Please note that filter--on-v4 was always wrong. how so? > You should fix your network instead. It’s a bandaid, not a fix. My ISP doesn't offer ipv6, so I'm not sure how to fix my network.. unless you mean disable ipv6 on everything? (which I'm not sure is even possible) Lee ___ 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: Slow recursive query performance on Windows x64
Run named with -4 option, that will disable IPv6.
Please note that filter--on-v4 was always wrong. You should fix your
network instead. It’s a bandaid, not a fix.
Ondrej
--
Ondřej Surý — ISC
> On 20 Jan 2020, at 04:38, Carl Byington via bind-users
> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>> On Sun, 2020-01-19 at 21:54 -0500, Steve Farr via bind-users wrote:
>> Does anyone know of a functionality that replaced the now-obsolete
>> filter--on-v4?
>
>plugin query "filter-.so" {
>filter--on-v4 yes;
>};
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEAREKAAYFAl4lII0ACgkQL6j7milTFsEkNgCcDPjGp5r6X7wvC0MJUcW5rFUz
> V4sAn2WL6OOPWwGUyKpMyWo27+5hphqx
> =MrO2
> -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
___
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: Slow recursive query performance on Windows x64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sun, 2020-01-19 at 21:54 -0500, Steve Farr via bind-users wrote:
> Does anyone know of a functionality that replaced the now-obsolete
> filter--on-v4?
plugin query "filter-.so" {
filter--on-v4 yes;
};
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAl4lII0ACgkQL6j7milTFsEkNgCcDPjGp5r6X7wvC0MJUcW5rFUz
V4sAn2WL6OOPWwGUyKpMyWo27+5hphqx
=MrO2
-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: Slow recursive query performance on Windows x64
Lee, that was fantastic. Thank you! Setting the whole IPv6 internet to be Bogus
worked like a charm. It would appear that even though IPv6 is unbound from the
NIC that BIND is running on, and even though BIND is only listening on v4
addresses, and even though I had the v6 roots commented out (all done
sequentially as troubleshooting measures), it was still pining away after the
v6 world.
Seems like maybe there ought to be a "cleaner" way to turn off v6 for queries
when it's totally not in use, rather than marking it as bogus. I tried setting
listen-on-v6 { none; };
or
query-source-v6 { none; };
(which turned out to be a syntax error / not allowed)
but it still delayed the queries unless I put in your suggestion server ::/0 {
bogus yes; }; -- really nice call.
By the way, I also tried filter--on-v4 yes; because none of my clients have
any v6 access either, so those 's probably aren't helpful to them, but the
log says this option is obsolete (and it does not actually filter out the
responses with the option enabled).
Does anyone know of a functionality that replaced the now-obsolete
filter--on-v4?
Thanks again, Lee!
-Steve
On 1/18/20, Steve Farr wrote:
>
> I don't have IPv6 connectivity through my ISP, and don't use it on my
> LAN, so I have it unchecked/not bound in Windows,
Same here.
When I tried running named on windows it didn't support the -4 option; the
workaround I was given was to add
server ::/0 { bogus yes; };
to named.conf so it wouldn't try to use ipv6. And maybe this is enabled/works
on windows now:
options {
filter--on-v4 yes;
}
> Basically, it looks like my DNS server sits on it for 3.2 seconds
> before asking the root for a referral.
Which is weird. Exactly how did you do the packet capture - as in, is it
possible you didn't capture everything to/from the server?
Lee
>
> From: Ondrej Sur
> Sent: Friday, January 17, 2020 3:27 PM
> To: Steve Farr
> Cc: bind-users@lists.isc.org
> Subject: Re: Slow recursive query performance on Windows x64
>
>
>
> Hi Steve,
>
>
>
> I would suggest to either bump debugging level in bind9 or use
> wireshark to look what s happening on the wire. My best guest is
> broken IPv6 connectivity, but it could be something completely
> different. Looking at the packets is a easiest way to get better
> understanding of the problem.
>
> Ondrej
>
> --
>
> Ondrej SurISC
>
>
>
>
>
> On 17 Jan 2020, at 20:52, Steve Farr via bind-users
>
> Hi there,
>
>
>
> I'm hoping perhaps someone can point me in a good direction for
> troubleshooting here I recently upgraded from BIND 9.9.10-P3 running
> in 32-bit Windows, to 9.14.9 running on 64-bit Windows. I've tried it
> in both Windows 10 and Windows 7, and the behavior is the same:
> Queries for addresses that aren't already cached take a long time
> (long enough that the client resolver often gives up and assumes the
> DNS server failed - perhaps
> 5-6 seconds). On a second attempt, it's usually in the cache and
> responds right away. The server has three views, two of which allow
> recursion, and it hosts a couple of authoritative domains (differing
> in content between the views, but present in all three). Queries for
> addresses in the domains that are hosted locally are fast, and so are queries
> for anything that's cached.
> I had to make a few tweaks to the config, jumping so many versions, in
> order to eliminate warnings about things like DNSSEC I also
> downloaded a fresh copy of the named.cache / root hints, as well as bind.keys.
>
>
>
> It's entirely possible that I just don't know what I'm doing.
>
>
>
> Any ideas what could be causing this? The old server occupied the same
> internal IP address (same firewall, same NAT, etc) so I don't tend to
> suspect the network, especially since it's reproducible (the old
> 32-bit box still works fast if I swap it back in). Here's my current
> config (feel free to critique it even if off-topic):
>
>
>
> // named.conf
>
> acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
>
> acl wifi { 192.168.64.0/24; };
>
> acl notifiers { [public IP removed for anonymity];};
>
>
>
> key "transfer-key" {
>
> algorithm hmac-md5;
>
> secret "[removed for security]";
>
> };
>
> server [same public IP as in acl notifiers] {
>
> keys { transfer-key; };
>
> };
>
>
>
> options {
>
> version "1.1.1.1";
>
> directory "C:\ISCBIND9\etc\namedb"; // Working directory
>
> pid-file "C:\ISCBIND9\var\named.pid";
>
> statistics-file "C:\ISCBIND9\var
Re: Slow recursive query performance on Windows x64
On 1/18/20, Steve Farr wrote:
>
> I don't have IPv6 connectivity through my ISP, and don't use it on my LAN,
> so I have it unchecked/not bound in Windows,
Same here.
When I tried running named on windows it didn't support the -4 option;
the workaround I was given was to add
server ::/0 { bogus yes; };
to named.conf so it wouldn't try to use ipv6. And maybe this is
enabled/works on windows now:
options {
filter--on-v4 yes;
}
> Basically, it looks like my DNS server sits on it for 3.2 seconds before
> asking the root for a referral.
Which is weird. Exactly how did you do the packet capture - as in, is
it possible you didn't capture everything to/from the server?
Lee
>
> From: Ondrej Surý
> Sent: Friday, January 17, 2020 3:27 PM
> To: Steve Farr
> Cc: bind-users@lists.isc.org
> Subject: Re: Slow recursive query performance on Windows x64
>
>
>
> Hi Steve,
>
>
>
> I would suggest to either bump debugging level in bind9 or use wireshark to
> look what’s happening on the wire. My best guest is broken IPv6
> connectivity, but it could be something completely different. Looking at the
> packets is a easiest way to get better understanding of the problem.
>
> Ondrej
>
> --
>
> Ondřej Surý — ISC
>
>
>
>
>
> On 17 Jan 2020, at 20:52, Steve Farr via bind-users
>
> Hi there,
>
>
>
> I'm hoping perhaps someone can point me in a good direction for
> troubleshooting here… I recently upgraded from BIND 9.9.10-P3 running in
> 32-bit Windows, to 9.14.9 running on 64-bit Windows. I've tried it in both
> Windows 10 and Windows 7, and the behavior is the same: Queries for
> addresses that aren't already cached take a long time (long enough that the
> client resolver often gives up and assumes the DNS server failed - perhaps
> 5-6 seconds). On a second attempt, it's usually in the cache and responds
> right away. The server has three views, two of which allow recursion, and it
> hosts a couple of authoritative domains (differing in content between the
> views, but present in all three). Queries for addresses in the domains that
> are hosted locally are fast, and so are queries for anything that's cached.
> I had to make a few tweaks to the config, jumping so many versions, in order
> to eliminate warnings about things like DNSSEC… I also downloaded a fresh
> copy of the named.cache / root hints, as well as bind.keys.
>
>
>
> It's entirely possible that I just don't know what I'm doing.
>
>
>
> Any ideas what could be causing this? The old server occupied the same
> internal IP address (same firewall, same NAT, etc) so I don't tend to
> suspect the network, especially since it's reproducible (the old 32-bit box
> still works fast if I swap it back in). Here's my current config (feel free
> to critique it even if off-topic):
>
>
>
> // named.conf
>
> acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
>
> acl wifi { 192.168.64.0/24; };
>
> acl notifiers { [public IP removed for anonymity];};
>
>
>
> key "transfer-key" {
>
> algorithm hmac-md5;
>
> secret "[removed for security]";
>
> };
>
> server [same public IP as in acl notifiers] {
>
> keys { transfer-key; };
>
> };
>
>
>
> options {
>
> version "1.1.1.1";
>
> directory "C:\ISCBIND9\etc\namedb"; // Working directory
>
> pid-file "C:\ISCBIND9\var\named.pid";
>
> statistics-file "C:\ISCBIND9\var\named.stats";
>
> memstatistics-file "C:\ISCBIND9\var\named.memstats";
>
> auth-nxdomain yes;
>
> listen-on { 192.168.63.23; 127.0.0.1; };
>
> tcp-clients 1024;
>
> max-cache-size 128M;
>
> allow-query { any; };
>
>recursion no;
>
>allow-recursion { none; };
>
>allow-query-cache { none; };
>
> allow-transfer { none; };
>
>allow-notify { notifiers; };
>
> notify no;
>
>
>
>dnssec-enable yes;
>
>dnssec-lookaside no;
>
>dnssec-validation yes;
>
>bindkeys-file "C:\ISCBIND9\etc\namedb\bind.keys";
>
> };
>
>
>
> view internal {
>
>match-clients { internal; };
>
>recursion yes;
>
>allow-query { internal; };
>
>allow-recursion { internal; };
>
>allow-query-cache { internal; };
>
>
>
>zone "." in {type hint; file "named.cache"; };
>
>
RE: Slow recursive query performance on Windows x64
dzo9ysms19bgt.cloudfront.net 2600:9000:2120:8e00:9:3aa4:d340:93a1
2600:9000:2120:6400:9:3aa4:d340:93a1 2600:9000:2120:8000:9:3aa4:d340:93a1
2600:9000:2120:8600:9:3aa4:d340:93a1
2600:9000:2120:4c00:9:3aa4:d340:93a1 2600:9000:2120:be00:9:3aa4:d340:93a1
2600:9000:2120:e000:9:3aa4:d340:93a1
2600:9000:2120:fe00:9:3aa4:d340:93a1
-Steve
From: Ondrej Surý
Sent: Friday, January 17, 2020 3:27 PM
To: Steve Farr
Cc: bind-users@lists.isc.org
Subject: Re: Slow recursive query performance on Windows x64
Hi Steve,
I would suggest to either bump debugging level in bind9 or use wireshark to
look what’s happening on the wire. My best guest is broken IPv6 connectivity,
but it could be something completely different. Looking at the packets is a
easiest way to get better understanding of the problem.
Ondrej
--
Ondřej Surý — ISC
On 17 Jan 2020, at 20:52, Steve Farr via bind-users mailto:bind-users@lists.isc.org> > wrote:
Hi there,
I'm hoping perhaps someone can point me in a good direction for troubleshooting
here… I recently upgraded from BIND 9.9.10-P3 running in 32-bit Windows, to
9.14.9 running on 64-bit Windows. I've tried it in both Windows 10 and Windows
7, and the behavior is the same: Queries for addresses that aren't already
cached take a long time (long enough that the client resolver often gives up
and assumes the DNS server failed - perhaps 5-6 seconds). On a second attempt,
it's usually in the cache and responds right away. The server has three views,
two of which allow recursion, and it hosts a couple of authoritative domains
(differing in content between the views, but present in all three). Queries for
addresses in the domains that are hosted locally are fast, and so are queries
for anything that's cached. I had to make a few tweaks to the config, jumping
so many versions, in order to eliminate warnings about things like DNSSEC… I
also downloaded a fresh copy of the named.cache / root hints, as well as
bind.keys.
It's entirely possible that I just don't know what I'm doing.
Any ideas what could be causing this? The old server occupied the same internal
IP address (same firewall, same NAT, etc) so I don't tend to suspect the
network, especially since it's reproducible (the old 32-bit box still works
fast if I swap it back in). Here's my current config (feel free to critique it
even if off-topic):
// named.conf
acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
acl wifi { 192.168.64.0/24; };
acl notifiers { [public IP removed for anonymity];};
key "transfer-key" {
algorithm hmac-md5;
secret "[removed for security]";
};
server [same public IP as in acl notifiers] {
keys { transfer-key; };
};
options {
version "1.1.1.1";
directory "C:\ISCBIND9\etc\namedb"; // Working directory
pid-file "C:\ISCBIND9\var\named.pid";
statistics-file "C:\ISCBIND9\var\named.stats";
memstatistics-file "C:\ISCBIND9\var\named.memstats";
auth-nxdomain yes;
listen-on { 192.168.63.23; 127.0.0.1; };
tcp-clients 1024;
max-cache-size 128M;
allow-query { any; };
recursion no;
allow-recursion { none; };
allow-query-cache { none; };
allow-transfer { none; };
allow-notify { notifiers; };
notify no;
dnssec-enable yes;
dnssec-lookaside no;
dnssec-validation yes;
bindkeys-file "C:\ISCBIND9\etc\namedb\bind.keys";
};
view internal {
match-clients { internal; };
recursion yes;
allow-query { internal; };
allow-recursion { internal; };
allow-query-cache { internal; };
zone "." in {type hint; file "named.cache"; };
zone "localhost" IN {type master; file "localhost.zone"; };
zone "0.0.127.in-addr.arpa" IN {type master; file "named.local";
};
[authoritative zones follow]
};
view wifi {
[basically the same as internal except different match-clients
statement and different zones]
};
view external {
match-clients { any; };
allow-recursion { none; };
allow-query-cache { none; };
recursion no;
allow-query {any; };
zone "." in {type hint; file "named.cache"; };
zone "localhost" IN {type master; file "localhost.zone"; };
zone "0.0.127.in-addr.arpa" IN {type master; file "named.local";
};
[authoritative zones follow]
};
Thanks for any help anyone may be a
Re: Slow recursive query performance on Windows x64
Hi Steve,
I would suggest to either bump debugging level in bind9 or use wireshark to
look what’s happening on the wire. My best guest is broken IPv6 connectivity,
but it could be something completely different. Looking at the packets is a
easiest way to get better understanding of the problem.
Ondrej
--
Ondřej Surý — ISC
> On 17 Jan 2020, at 20:52, Steve Farr via bind-users
> wrote:
>
>
> Hi there,
>
> I'm hoping perhaps someone can point me in a good direction for
> troubleshooting here… I recently upgraded from BIND 9.9.10-P3 running in
> 32-bit Windows, to 9.14.9 running on 64-bit Windows. I've tried it in both
> Windows 10 and Windows 7, and the behavior is the same: Queries for addresses
> that aren't already cached take a long time (long enough that the client
> resolver often gives up and assumes the DNS server failed - perhaps 5-6
> seconds). On a second attempt, it's usually in the cache and responds right
> away. The server has three views, two of which allow recursion, and it hosts
> a couple of authoritative domains (differing in content between the views,
> but present in all three). Queries for addresses in the domains that are
> hosted locally are fast, and so are queries for anything that's cached. I had
> to make a few tweaks to the config, jumping so many versions, in order to
> eliminate warnings about things like DNSSEC… I also downloaded a fresh copy
> of the named.cache / root hints, as well as bind.keys.
>
> It's entirely possible that I just don't know what I'm doing.
>
> Any ideas what could be causing this? The old server occupied the same
> internal IP address (same firewall, same NAT, etc) so I don't tend to suspect
> the network, especially since it's reproducible (the old 32-bit box still
> works fast if I swap it back in). Here's my current config (feel free to
> critique it even if off-topic):
>
> // named.conf
> acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
> acl wifi { 192.168.64.0/24; };
> acl notifiers { [public IP removed for anonymity];};
>
> key "transfer-key" {
> algorithm hmac-md5;
> secret "[removed for security]";
> };
> server [same public IP as in acl notifiers] {
> keys { transfer-key; };
> };
>
> options {
> version "1.1.1.1";
> directory "C:\ISCBIND9\etc\namedb"; // Working directory
> pid-file "C:\ISCBIND9\var\named.pid";
> statistics-file "C:\ISCBIND9\var\named.stats";
> memstatistics-file "C:\ISCBIND9\var\named.memstats";
> auth-nxdomain yes;
> listen-on { 192.168.63.23; 127.0.0.1; };
> tcp-clients 1024;
> max-cache-size 128M;
> allow-query { any; };
>recursion no;
>allow-recursion { none; };
>allow-query-cache { none; };
> allow-transfer { none; };
>allow-notify { notifiers; };
> notify no;
>
>dnssec-enable yes;
>dnssec-lookaside no;
>dnssec-validation yes;
>bindkeys-file "C:\ISCBIND9\etc\namedb\bind.keys";
> };
>
> view internal {
>match-clients { internal; };
>recursion yes;
>allow-query { internal; };
>allow-recursion { internal; };
>allow-query-cache { internal; };
>
>zone "." in {type hint; file "named.cache"; };
>zone "localhost" IN {type master; file "localhost.zone"; };
>zone "0.0.127.in-addr.arpa" IN {type master; file
> "named.local"; };
>[authoritative zones follow]
> };
>
> view wifi {
>[basically the same as internal except different match-clients
> statement and different zones]
> };
>
> view external {
>match-clients { any; };
>allow-recursion { none; };
>allow-query-cache { none; };
>recursion no;
>allow-query {any; };
>
>zone "." in {type hint; file "named.cache"; };
>zone "localhost" IN {type master; file "localhost.zone"; };
>zone "0.0.127.in-addr.arpa" IN {type master; file
> "named.local"; };
>[authoritative zones follow]
> };
>
>
> Thanks for any help anyone may be able to offer!
>
> -Steve
>
> ___
> 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
___
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
