Some slow recursive queries issues

Re: Some slow recursive queries issues

From:

Date:

Time:

The response is different depending on the source of the query. If
you query from a machine local to the server, the response is fast,
but if you query from your Comcast address, the response is slow.
This suggests the problem isn't in your server, but in Comcast. On
the other hand, queries sent to other servers from your Comcast
address are answered quickly. This suggests the problem is in your
server. Perhaps there's something peculiar going on between Comcast
and your server. For example, perhaps there's a problematic
interaction between some DNS proxy at Comcast and your BIND 9.3.0
server, a problem that doesn't exist with other DNS servers.

Regarding the email server and the blacklist: Your server hosts this
black list, right? If so, there's no recursion taking place - your
server simply answers from authoritative data. (If the assumption's
not correct, then this answer is not correct either.)

Yes, using 'dig @server query-name [options...]' achieves the same
effect as putting the server's IP in the TCP/IP settings of a
machine. There's no way to have dig show debug output, but there's
not much to show - it sends the query you specify and displays the
results. If you want to see more detail, use a packet sniffer.

If you set your QuickDNS log severity level to "debug", and set the
debug level to either 10 or 100, you should be able to see all the
details (along with lots of other stuff).

For details of the flags, look on the second line of the first table here:
<http://www.networksorcery.com/enp/protocol/dns.htm>

Chris Buxton
Men & Mice - Making DNS Easy

At 3:44 PM -0800 1/21/05, Scott Haneda wrote:
>This is gonna be long :-)
>
>options {
> directory "/var/named";
> statistics-file "named.stats";
> allow-recursion { 64.84.37.0/26; 24.5.47.136; 194.100.88.239; };
> allow-transfer { 198.144.200.122; 198.144.200.118; };
> transfer-source 64.84.37.14;
>};
>
>The 24.5.47.136 is me, on my comcast connection. I use comcast as my
>recursive resolver as I have found it to be fast and reliable. For reasons
>that are beyond me, I can not get the DHCP DNS servers from comcast to
>trickle down to laptops on my network wirelessly. I have to enter in some
>IP in the tcp/ip settings to get the machine to resolve hostnames. No big
>deal, I will just use my DNS server, hence the allow-recursion entry for my
>comcast IP.
>
>What I notice, is it is horribly slow at doing its stuff. At first I
>thought this was simply due to my DNS server never having seen any of these
>domain requests, so it was not pulling from a cache, so it would be somewhat
>slower. I am not so sure anymore.
>
>* Excuse the random domain names, I need ones I have not hit before to test
>this out.
>
>Here is a test from comcast to my NS:
>dig @ns1.hostwizard.com twig.com
>
>; <<>> DiG 9.2.2 <<>> @ns1.hostwizard.com twig.com
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25590
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>;; QUESTION SECTION:
>;twig.com. IN A
>
>;; AUTHORITY SECTION:
>twig.com. 10800 IN SOA ns0.twig.com.
>hostmaster.twig.com. 2004113001 3600 1800 2419200 3600
>
>;; Query time: 4105 msec
>;; SERVER: 64.84.37.14#53(ns1.hostwizard.com)
>;; WHEN: Fri Jan 21 15:33:22 2005
>;; MSG SIZE rcvd: 7
>
>As you can see, 4105 msec, pretty long, second time of course is plenty fast
>at ;; Query time: 59 msec
>
>Now lets try a new one to some other DNS server, that I know also would not
>have a cache of it as it is not very busy:
>
>dig @dns3.intermag.com cd.com
>
>; <<>> DiG 9.2.2 <<>> @dns3.intermag.com cd.com
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 75
>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;cd.com. IN A
>
>;; ANSWER SECTION:
>cd.com. 86400 IN A 64.49.213.239
>
>;; AUTHORITY SECTION:
>cd.com. 86400 IN NS ns3.domainsystems.com.
>cd.com. 86400 IN NS ns4.domainsystems.com.
>
>;; Query time: 124 msec
>;; SERVER: 198.144.200.118#53(dns3.intermag.com)
>;; WHEN: Fri Jan 21 15:35:27 2005
>;; MSG SIZE rcvd: 90
>
>As you can see, it was much faster sending back something to me in 124 msec.
>
>One more test, this time to a old OS 9 DNS machine:
>dig @ns2.concretegrinding.com god.com
>
>; <<>> DiG 9.2.2 <<>> @ns2.concretegrinding.com god.com
>;; global options: printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21990
>;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
>;; QUESTION SECTION:
>;god.com. IN A
>
>;; ANSWER SECTION:
>god.com. 7200 IN A 64.40.102.41
>
>;; AUTHORITY SECTION:
>god.com. 7200 IN NS ns1.verticalaxis.com.
>god.com. 7200 IN NS ns2.verticalaxis.com.
>
>;; ADDITIONAL SECTION:
>ns1.verticalaxis.com. 172800 IN A 64.40.102.21
>ns2.verticalaxis.com. 172800 IN A 64.40.102.1
>
>;; Query time: 204 msec
>;; SERVER: 66.196.253.180#53(ns2.concretegrinding.com)
>;; WHEN: Fri Jan 21 15:36:28 2005
>;; MSG SIZE rcvd: 122
>
>As you can see, also plenty fast.
>
>If I ssh into my colo network and run the same tests, it is very fast, so
>being closer to the ns1.hostwizard.com machine solves the problem. What is
>odd, and I may not understand this, is I allow a client to point DNS based
>email blacklists to my DNS zone for personal blacklists, and the logs show
>those lookups happen in well under 100ms all the time. However, that email
>server is not listed in my allow-recusrion, some my lack of understanding on
>how that relates may be part of it.
>
>Does running `dig @ns host.com` in the CLI more or less do the same thing
>that entering in the ip in the tcp/ip settings on my machine would do? What
>is different about that scenario and say, for example, a email server
>looking up A records that are in my DNS server? In the case of a email
>server, all lookups would more or less be non cached, since pretty much all
>email comes from many different places, so inverse the IP and add on
>bl.hostwizard.com to it would pretty much always be a new non cached hit.
>That being said, it is fast, and I can not get that same speed on my comcast
>line.
>
>One test I was thinking is to install the demo on a new machine and
>allow-recursion and see if the problem goes away, if it does, I know it is
>machine related or software related.
>
>Is there any way to tell `dig` to show me what it is doing just after I send
>the command, in real time, much like `traceroute` does?
>
>If I tail -f on the quickdns.log file, with "query logging" on, I can see
>the second I send the dig command, qdns sees it, it seems to be sending out
>the answer that is taking a while. The qdns logs don't seem to tell me much
>more than the incoming request, is there some more verbose option to look
>for?
>
>At this point, I am not sure where to go to figure out what is happening
>here. Any advise is appreciated. Also, can someone point me to a link that
>tells me what the flags that dig sends back to you mean, I tried man dig and
>man resolver to no avail.
>--
>-------------------------------------------------------------
>Scott Haneda Tel: 415.898.2602
><http://www.newgeo.com> Fax: 313.557.5052
><scott@newgeo.com> Novato, CA U.S.A.

Sales:
888/4-DPOINT

Support:
858/452-3696