System Resolver Test App?

[david at from525.com]

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.