On Wed, 11 Nov 2009 20:06:11 -0600, "da...@from525.com" <da...@from525.com> wrote: > On Thu, 12 Nov 2009 10:01:38 +0900, Stephane Bortzmeyer <bortzme...@nic.fr> > wrote: >> On Wed, Nov 11, 2009 at 05:00:03PM -0600, >> da...@from525.com <da...@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. > > Stephane, > > 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 a > specific hostname. Funny thing is, when I perform other queries for other > 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. I > have captured previous tcpdumps and didn't notice anything out of the norm, > but there was alot of other network chatter. The app should let me capture > a more concise tcpdump for further examination. Is there any way you could > incorporate resolver errors being sent to stdout? > > Thanks, > David Porsche > _______________________________________________ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
Thanks All, 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. Thanks, David Porsche _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users