System Resolver Test App?
david at from525.com
david at from525.com
Thu Nov 12 16:11:36 UTC 2009
On Thu, 12 Nov 2009 08:04:35 -0600, "david at from525.com" <david at from525.com>
wrote:
> On Thu, 12 Nov 2009 01:48:02 -0500, Barry Margolin <barmar at alum.mit.edu>
> wrote:
>> In article <mailman.971.1257996722.14796.bind-users at lists.isc.org>,
>> "david at from525.com" <david at 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
More information about the bind-users
mailing list