Resolution fails, running nslookup causes it to succeed

  • Thread starter Thread starter Jeff Barnes
  • Start date Start date
J

Jeff Barnes

Hi
Browsing to download.nai.com fails due to our internal DNS servers not able
to resolve the hostname. Then if we run nslookup against our DNS servers
and query the hostname that way, it succeeds and subsequently DNS client
name resolution (and browsing) also works for a little while afterward.

Originally when we looked at this problem, download.nai.com resolved to an
AKAMAI address; but now it no longer does so.

Any suggestions?
 
Jeff Barnes said:
Hi
Browsing to download.nai.com fails due to our internal DNS servers not
able to resolve the hostname. Then if we run nslookup against our DNS
servers and query the hostname that way, it succeeds and subsequently DNS
client name resolution (and browsing) also works for a little while
afterward.
Click to expand...

Usually such behavior is do to two-three things (two bad, one good) working
together:

a) Long delay in INITIAL resolution so the client timesout (server not
found)
b) NSlookup asks the server explicitly to go get that name and then of
course
the DNS server holds it in cache for the NEXT client.

So where is #3, and how come it doesn't just work without the (extra)
NSLookup request?

Client side caching of NEGATIVE results also enters the picture.
Modern clients cache (even) negative results for 5 minutes, and so
by the time you fuss with NSlookup and so on, the client cache has
timed out and now the server has the answer.

How to confirm:
Don't do the NSLookup.
Attempt to visit the web page. (get the error)
Immediately go to the command line and type:
ipconfig /flushDNS

Hit retry in the browser. If the client was caching bad (not found)
info, and the server has eventually received the answer and is
now caching it then this will work.
Originally when we looked at this problem, download.nai.com resolved to an
AKAMAI address; but now it no longer does so.
Click to expand...

Likely irrelevant except that it may reflect flaky DNS servers on there
part.

It could also be due to the (more obscure) problem Nai.com having
multiple UNREPLICATED DNS servers, i.e., one time you hit one
and another time you hit the other... but client server caching and timeouts
are my bet.

Let us know....
 
Hi
Thanks for your reply. I tried the following as proposed:
How to confirm:
Don't do the NSLookup.
Attempt to visit the web page. (get the error)
Immediately go to the command line and type:
ipconfig /flushDNS

Hit retry in the browser. If the client was caching bad (not found)
info, and the server has eventually received the answer and is
now caching it then this will work.
Click to expand...

Resolution still failed after clearing the client cache and hitting retry.
/displaydns did not contain any resolution information (either right or
wrong) and Network Monitor indicates a server failure (DNS: ............0010
= Server failure)

Ethereal indicates that a standard query for download.nai.com returns
download.nai.com.edgesuite.net, and from the DNS server back to my client
returns "server failure"


Herb Martin said:
in message
Hi
Browsing to download.nai.com fails due to our internal DNS servers not
able to resolve the hostname. Then if we run nslookup against our DNS
servers and query the hostname that way, it succeeds and subsequently DNS
client name resolution (and browsing) also works for a little while
afterward.
Click to expand...

Usually such behavior is do to two-three things (two bad, one good)
working
together:

a) Long delay in INITIAL resolution so the client timesout (server not
found)
b) NSlookup asks the server explicitly to go get that name and then of
course
the DNS server holds it in cache for the NEXT client.

So where is #3, and how come it doesn't just work without the (extra)
NSLookup request?

Client side caching of NEGATIVE results also enters the picture.
Modern clients cache (even) negative results for 5 minutes, and so
by the time you fuss with NSlookup and so on, the client cache has
timed out and now the server has the answer.

How to confirm:
Don't do the NSLookup.
Attempt to visit the web page. (get the error)
Immediately go to the command line and type:
ipconfig /flushDNS

Hit retry in the browser. If the client was caching bad (not found)
info, and the server has eventually received the answer and is
now caching it then this will work.
Originally when we looked at this problem, download.nai.com resolved to
an AKAMAI address; but now it no longer does so.
Click to expand...

Likely irrelevant except that it may reflect flaky DNS servers on there
part.

It could also be due to the (more obscure) problem Nai.com having
multiple UNREPLICATED DNS servers, i.e., one time you hit one
and another time you hit the other... but client server caching and
timeouts
are my bet.

Let us know....
Any suggestions?
Click to expand...

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Click to expand...
 
Jeff Barnes said:
Hi
Thanks for your reply. I tried the following as proposed:

Resolution still failed after clearing the client cache and hitting retry.
/displaydns did not contain any resolution information (either right or
wrong) and Network Monitor indicates a server failure (DNS:
............0010 = Server failure)
Click to expand...

Most common reason (that I hear) for "Server failure" is that
some has two DNS servers forwarding to each other (mutually).
Ethereal indicates that a standard query for download.nai.com returns
download.nai.com.edgesuite.net, and from the DNS server back to my client
returns "server failure"
Click to expand...

But I don't see how that would jibe with mutual forwarding.

Go to the DNS involved and enable debug logging for the
appropriate queries and responses and try it then.
(One from each area of the log checkboxs is requires at a
MINIMUM.) Don't leave this on too long on even a moderately
busy DNS server because they logs will grow faster than you
likely expect.

If none of this leads anywhere, that server failure would make
me try a "REPAIR INSTALL" pretty soon. (Some DLL damaged
or similar problem.)


--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Herb Martin said:
in message
Hi
Browsing to download.nai.com fails due to our internal DNS servers not
able to resolve the hostname. Then if we run nslookup against our DNS
servers and query the hostname that way, it succeeds and subsequently
DNS client name resolution (and browsing) also works for a little while
afterward.
Click to expand...

Usually such behavior is do to two-three things (two bad, one good)
working
together:

a) Long delay in INITIAL resolution so the client timesout (server
not found)
b) NSlookup asks the server explicitly to go get that name and then
of course
the DNS server holds it in cache for the NEXT client.

So where is #3, and how come it doesn't just work without the (extra)
NSLookup request?

Client side caching of NEGATIVE results also enters the picture.
Modern clients cache (even) negative results for 5 minutes, and so
by the time you fuss with NSlookup and so on, the client cache has
timed out and now the server has the answer.

How to confirm:
Don't do the NSLookup.
Attempt to visit the web page. (get the error)
Immediately go to the command line and type:
ipconfig /flushDNS

Hit retry in the browser. If the client was caching bad (not found)
info, and the server has eventually received the answer and is
now caching it then this will work.
Originally when we looked at this problem, download.nai.com resolved to
an AKAMAI address; but now it no longer does so.
Click to expand...

Likely irrelevant except that it may reflect flaky DNS servers on there
part.

It could also be due to the (more obscure) problem Nai.com having
multiple UNREPLICATED DNS servers, i.e., one time you hit one
and another time you hit the other... but client server caching and
timeouts
are my bet.

Let us know....
Any suggestions?
Click to expand...

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Click to expand...
Click to expand...
 
Back
Top