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ý <ond...@isc.org>
Sent: Friday, January 17, 2020 3:27 PM
To: Steve Farr <st...@farrhomestead.com>
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 <bind-users@lists.isc.org
<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 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 <mailto: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
