System Resolver Test App?
david at from525.com
david at from525.com
Thu Nov 12 03:31:51 UTC 2009
On Wed, 11 Nov 2009 20:06:11 -0600, "david at from525.com" <david at from525.com>
> On Thu, 12 Nov 2009 10:01:38 +0900, Stephane Bortzmeyer
<bortzmeyer at nic.fr>
>> On Wed, Nov 11, 2009 at 05:00:03PM -0600,
>> david at from525.com <david at from525.com> wrote
>> a message of 60 lines which said:
>>> I am wondering if anyone knows of an app similar to nslookup or
>>> dig that actually uses the system resolver.
>> C source attached. Compile, for instance, with:
>> gcc -o resolve-name resolve-name.c
>>> I am basically trying to uinderstand why the system resolver was
>>> getting stuck on the third entry within the resolv.conf while it
>>> should have tried one of the first two working DNS servers first.
>> Not sure it will help.
> Thanks for that bit of c it works great and does just what I was hoping
> for. I was able to reproduce the almost 13 second delay while looking up
> specific hostname. Funny thing is, when I perform other queries for
> hostnames the third invalid DNS server mentioned in the resolv.conf does
> not seem to be a problem. When I remove the third invalid entry and
> perform the same query with your application the delay is non existent.
> have captured previous tcpdumps and didn't notice anything out of the
> but there was alot of other network chatter. The app should let me
> a more concise tcpdump for further examination. Is there any way you
> incorporate resolver errors being sent to stdout?
> David Porsche
> bind-users mailing list
> bind-users at lists.isc.org
I think between Stephane's test app and some snoop data I have a better
idea of what is going on. It seems as if the local resolver starts by
issuing ipv6 requests to the three name servers mentioned in resolv.conf.
The first two valid DNS servers (not configured for ipv6) each respond
back stating they are not authoritative for the domain in question causing
the subsequent servers to be queried. The resolver finds itself querying
the third bogus name server and has to wait for the 5 second time out. The
resolver then repeats the whole process for ipv6 adding another 5 seconds
to the delay (total of 10 now). The resolver then finally starts the whole
process again for ipv4 and gets the proper answer with the first query.
More information about the bind-users