Slow recursive query performance on Windows x64
Steve Farr
steve at farrhomestead.com
Sat Jan 18 13:51:53 UTC 2020
Hi Ondřej,
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, though I tried reversing that and it didn't seem to make a difference… Below is a text summary of a wireshark capture showing my client at 192.168.65.40 querying my DNS server (192.168.63.23) for www.toyota.com (I wasn't sure how the listserv would feel about attachments but I could do that in the future if it's better). I have the debug output from this same exchange, too, if that would be helpful.
Basically, it looks like my DNS server sits on it for 3.2 seconds before asking the root for a referral. Then it proceeds pretty quickly through the chain until it gets to the last step, querying for the actual A records, and it sits on it again for 3 seconds between pack #6 and #11 before asking the question. Every time it queries a remote server, it gets a timely response, but it's doing a lot of waiting in between on my end. The system is not at all taxed on resources as far as RAM, CPU, etc… Thoughts?
No. Time Source Destination Protocol Length Info
1 0.000000 192.168.65.40 192.168.63.23 DNS 74 Standard query 0x0031 A www.toyota.com
2 2.004672 192.168.65.40 192.168.63.23 DNS 74 Standard query 0x0032 AAAA www.toyota.com
3 3.247628 192.168.63.23 156.154.64.102 DNS 97 Standard query 0xad4f A www.toyota.com OPT
4 3.293385 156.154.64.102 192.168.63.23 DNS 127 Standard query response 0xad4f A www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net OPT
5 3.296917 192.168.63.23 205.251.197.26 DNS 111 Standard query 0xcc9e A dzo9ysms19bgt.cloudfront.net OPT
6 3.342506 205.251.197.26 192.168.63.23 DNS 236 Standard query response 0xcc9e A dzo9ysms19bgt.cloudfront.net NS ns-1038.awsdns-01.org NS ns-1930.awsdns-49.co.uk NS ns-243.awsdns-30.com NS ns-726.awsdns-26.net OPT
7 4.009582 192.168.65.40 192.168.63.23 DNS 74 Standard query 0x0033 A www.toyota.com
8 5.244283 192.168.63.23 156.154.64.102 DNS 97 Standard query 0x2f46 AAAA www.toyota.com OPT
9 5.285546 156.154.64.102 192.168.63.23 DNS 127 Standard query response 0x2f46 AAAA www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net OPT
10 6.013691 192.168.65.40 192.168.63.23 DNS 74 Standard query 0x0034 AAAA www.toyota.com
11 6.585975 192.168.63.23 205.251.196.14 DNS 111 Standard query 0xa369 A dzo9ysms19bgt.cloudfront.net OPT
12 6.629538 205.251.196.14 192.168.63.23 DNS 300 Standard query response 0xa369 A dzo9ysms19bgt.cloudfront.net A 99.84.127.20 A 99.84.127.33 A 99.84.127.55 A 99.84.127.5 NS ns-1038.awsdns-01.org NS ns-1930.awsdns-49.co.uk NS ns-243.awsdns-30.com NS ns-726.awsdns-26.net OPT
13 6.631563 192.168.63.23 192.168.65.40 DNS 180 Standard query response 0x0031 A www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net A 99.84.127.5 A 99.84.127.20 A 99.84.127.33 A 99.84.127.55
14 6.631684 192.168.63.23 192.168.65.40 DNS 180 Standard query response 0x0033 A www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net A 99.84.127.33 A 99.84.127.20 A 99.84.127.5 A 99.84.127.55
15 7.709160 192.168.63.23 205.251.196.14 DNS 111 Standard query 0x84c7 AAAA dzo9ysms19bgt.cloudfront.net OPT
16 7.752769 205.251.196.14 192.168.63.23 DNS 460 Standard query response 0x84c7 AAAA dzo9ysms19bgt.cloudfront.net AAAA 2600:9000:2120:8000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:e000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:6400:9:3aa4:d340:93a1 AAAA 2600:9000:2120:be00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8e00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:fe00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:4c00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8600:9:3aa4:d340:93a1 NS ns-1038.awsdns-01.org NS ns-1930.awsdns-49.co.uk NS ns-243.awsdns-30.com NS ns-726.awsdns-26.net OPT
17 7.754830 192.168.63.23 192.168.65.40 DNS 340 Standard query response 0x0032 AAAA www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net AAAA 2600:9000:2120:fe00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:4c00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8600:9:3aa4:d340:93a1 AAAA 2600:9000:2120:e000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:6400:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8e00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:be00:9:3aa4:d340:93a1
18 7.754983 192.168.63.23 192.168.65.40 DNS 340 Standard query response 0x0034 AAAA www.toyota.com CNAME dzo9ysms19bgt.cloudfront.net AAAA 2600:9000:2120:8e00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:6400:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:8600:9:3aa4:d340:93a1 AAAA 2600:9000:2120:4c00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:be00:9:3aa4:d340:93a1 AAAA 2600:9000:2120:e000:9:3aa4:d340:93a1 AAAA 2600:9000:2120:fe00:9:3aa4:d340:93a1
-Steve
From: Ondrej Surý <ondrej at isc.org>
Sent: Friday, January 17, 2020 3:27 PM
To: Steve Farr <steve at farrhomestead.com>
Cc: bind-users at 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 <bind-users at lists.isc.org <mailto:bind-users at 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 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 at lists.isc.org <mailto:bind-users at lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200118/50f93026/attachment-0001.htm>
More information about the bind-users
mailing list