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