On Thu, 12 Nov 2009 01:48:02 -0500, Barry Margolin <bar...@alum.mit.edu> wrote: > In article <mailman.971.1257996722.14796.bind-us...@lists.isc.org>, > "da...@from525.com" <da...@from525.com> wrote: > >> 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. >> > > Do you mean that it's issuing requests using IPv6, or it's using IPv4 to > send requests for AAAA records? >
The latter. Using IPv4 to send requests for AAAA records. >> 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 > > Which servers are you talking about now, the servers in resolv.conf, or > the servers for the domain you're querying? The latter should not > respond that they're not authoritative. Authority is not specific to IP > versions, it just goes by names. A server is either authoritative for > foo.com or it isn't, it can't be authoritative for foo.com's IPv4 data > but not for its IPv6 data. I was talking about the servers mentioned in the resolv.conf. So here goes a second try,..... There are (were) three servers mentioned in the resolv.conf. We can reference them going forward as nameserver1, nameserver2 & nameserver3. Nameserver3 is a bogus invalid IP belonging to nothing, while nameserver1 & nameserver2 are legitimate nameservers. Now it is important to know that the resource record that was causing issue while attempting to query is a CNAME to another resource record. The "other" resource record lives in DNS space that has been delegated out. In this case it has been delegated out to a Citrix Netscaler load balancing device. I believe the issue to actually be the fault of the Netscaler as it seems as if it does not handle the AAAA records as it should. When the initial query is issued to the local resolver snoop data shows that both nameserver1 & namserver2 send a response back with an error message of "Server failure" (when the AAAA record is requested). The error message then triggers the loop of subsequent queries and creates the delays until the resolver issues the query for the A record. At this point everything works as normal. I plan to do some more tests to confirm my theory on the Netscaler. Please let me know if I am just talking nonsense,.............. > >> 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. > > If you're not actually using IPv6, you might consider disabling it on > your system. That should stop all the unnecessary v6 lookups. It is not my system. I was just brought in to help find the issue. I can suggest this to the proper system admin. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
