On Thu, 12 Nov 2009 08:04:35 -0600, "da...@from525.com" <da...@from525.com> wrote: > 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. All, I have confirmed the issue with the Citrix Netscaler and AAAA records which is documented at the link bellow. Thanks for everyone's help figuring this out. http://support.citrix.com/article/CTX117947 Thanks, David Porsche _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
