You've come to this page because you've used nslookup.
This is the Frequently Given Answer to such usage.
(You can find a different approach to this answer on Will Yardley's nslookup flaws page, which preserves 2001-06-07 Usenet posts by Brad Knowles and Barry Margolin.)
You are using nslookup. Don't.
nslookup is badly designed. It's a very poor tool for several reasons. It has been widely acknowledged for several years that it is a bad tool. Even the company that writes BIND acknowledged this for a while and stated that nslookup is deprecated and may be removed from future releases of BIND, although it later backpedaled on this whilst leaving several of the design flaws in. (Even though your particular operating system vendor may have packaged it separately, nslookup is in fact a diagnostic tool that is a part of the BIND package.)
Stop using nslookup right now. Start using better, less flawed, tools instead. Almost every DNS server software package comes bundled with tools to manually query the DNS for diagnostic purposes. Use the tools that came with the package that you have.
Even BIND itself comes with better tools. The company that writes BIND in fact rewrote nslookup for BIND version 9.x . It no longer contained one of the daft design flaws. But it also no longer contained some of the functionality of the original tool, and printed a prominent warning message every time that it is invoked stating a BIND-centric version of what this page recommends — i.e. that one should stop using nslookup in favour of host and dig.
Here are several of the more major flaws in nslookup.
This daft design flaw in nslookup is threefold:
Before performing the query that you actually instructed it to perform, nslookup performs other, hidden, queries. One of these is a reverse lookup on the IP address of the server that it is sending the query to. It prints the result as the name of the server.
This query is pointless. You gave nslookup that IP address yourself, either indirectly by specifying a domain name or directly by supplying an explicit IP address, when you told it what server to query. If you specified the server by name, nslookup is just wasting its time trying to turn the IP address back into a name. It already has the name that yielded the IP address in the first place. If you specified the server by IP address, nslookup has no business assuming either that you are interested in the reverse mapping of that IP address to a domain name (If you were, you would have issued the query explicitly. You are invoking a tool that performs DNS queries, after all.) or that such a reverse mapping even exists at all. (There is no requirement for it to exist. Not all IP addresses need have domain names associated with them.)
A far better design would simply use the information that you told it to use exactly as it stands, without trying to be "helpful" when repeating it back to you.
nslookup has its own internal DNS client. Unfortunately, it uses this for every query that it makes. This includes the reverse lookup on the IP address of the current server. This means that nslookup sends the "PTR" query for the inverse lookup to the very server whose IP address is being looked up.
It has no business doing this. There's no justification whatsoever for the assumption that every content DNS server serves up the reverse lookup domain for the IP address on which it happens to be listening.
A far better design would perform the reverse lookup through the ordinary system-wide DNS client library, and your ordinary proxy DNS servers.
If the reverse lookup fails, nslookup prints an error message:
*** Can't find server name for address 10.0.0.1: … *** Default servers are not available
Or (in the case of the "small" nslookup in BusyBox when used in conjunction with the musl C library):
nslookup: can't resolve '(null)'
If it continues, you should consider yourself lucky. Most flavours of nslookup simply abort at this point, without performing the query that they were actually instructed to perform at all.
nslookup doesn't use the system-wide DNS client libraries that everything else uses for name and address lookups (usually the BIND DNS client library). It has its own internal DNS client, allowing it to explicitly control things such as the search path, target server, recursion desired flag, and so forth. However, several of the aspects of nslookup's internal DNS client are different to the system-wide DNS client libraries:
nslookup's timeout/retry algorithm is different to that of the BIND DNS client library. When multiple proxy DNS servers are listed in /etc/resolv.conf, the BIND DNS client library tries all of them at each timeout value before proceeding to a longer timeout value. nslookup's client library, in contrast, tries all timeout values against a single proxy DNS server before proceeding to the next. (In other words: The BIND DNS client library uses the order "ABCABCABC…" whereas nslookup's DNS client uses the order "AAA…BBB…CCC…".)
Once nslookup receives a response from a proxy DNS server, it locks on to that server for the remainder of the session (or until the server command is used). The BIND DNS client library tries all configured proxy DNS servers every time, and doesn't remember which proxy DNS server to use from one lookup to the next.
By default, nslookup prints its interpretation of the responses that it receives, rather than the raw response. This interpretation is often misleading. For example: nslookup interprets a partial answer ending in a referral as "no answer".
Even with all of its debugging options turned on, nslookup doesn't display all of the content of the responses that it receives.
BIND and its tools, including nslookup, are often bundled with the operating system by the vendor. Several vendors supply versions of BIND and its tools that the vendor has made modifications to. These vendors supply their own modified versions of nslookup that "for convenience" bypass the DNS and use extraneous sources of information such as /etc/hosts and NIS.
Such modifications make nslookup unsuitable as a tool for DNS problem diagnosis, since one cannot determine whether a problem that (such a modified version of) nslookup reports is a DNS problem or a problem with performing lookups using one of the other sources of information.