Why does nslookup give NXDOMAIN but dig works fine?

I don't see an exact answer for this elsewhere, so I'm going to be brave and ask here. I have a linode and have set up a DNS A record for my host which I'll call A.wc.net. When I look it up using nslookup on A.wc.net, I get this kind of answer:

#  running on A.wc.net:  
root@linode (etc ): nslookup A.wc.net
Server:         173.255.243.5
Address:        173.255.243.5#53

** server can't find A.wc.net: NXDOMAIN

However, from any other machine, nslookup gives the right result:

@HomeMac (~ (BARE:master)): nslookup A.wc.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   A.wc.net
Address: 173.255.111.911  (number changed for my protection ;-) 

Also, if I run dig on the host A.wc.net:

root@linode (etc ): dig @ns1.linode.com A.wc.net

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns1.linode.com A.wc.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55398
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;A.wc.net.                IN      A

;; ANSWER SECTION:
A.wc.net. 86400   IN      A       173.255.111.911  (number changed for my protection ;-) 

My question is, why does

nslookup A.wc.net

run on the host A.wc.net itself uniquely fail to find the correct answer, when the same command run on other hosts succeeds, and

dig @ns1.linode.com A.wc.net

on the host A.wc.net itself fails?

Solution 1:

In this answer I am making an assumption: You created a new A record for the domain and started making queries immediately from other systems.

Let's look at what you were really asking in each of your three examples.

Example 1: You asked nslookup to find an A-record for A.wc.net, you did not tell nslookup what nameserver to use to look that record up. The OS has some defaults nslookup tells you that it's using a nameserver at 173.255.243.5 to attempt to lookup. That lookup fails.

Example 2: you asked nslookup on a different computer to lookup A.wc.net again without telling nslookup what nameserver to use. This connection is using google DNS at 8.8.8.8 by default. (personal rant} google DNS is fast but I refuse to give google more information about me than they need to know. {/personal rant} Google had an answer for you and told you, it also told you that it's not authoritative DNS for this domain--that essentially ~in simple words~ says: this nameserver is not the authority for this domain, here is an answer for you however my record might be cached, there might be a more recent record at the authoritative DNS for this domain. (fully explaining authoritative/non-authoritative answers etc is really way beyond the scope of your question, but the fast answer is: the authoritative nameservers are the nameservers that you set the domain to use. in the case of wc.net at the time I'm posting this answer wc.net's nameservers are UDNS2.ULTRADNS.NET and UDNS1.ULTRADNS.NET and they would provide authoritative answers if you told dig or nslookup to use either of those servers for the query).

Example 3: you asked dig to use the nameserver @ns1.linode.com to lookup A.wc.net and it found an A-record and gave it to you. This time we got one additional piece of information TTL or Time-To-Live which is set for 86400 seconds or 24 hours.

The significance of this is that the non-authoritative nameservers that handle queries (and in all 3 examples you were using non-authoritative nameservers for wc.net) will look in their own cache first to see if it already knows a non-expired answer to the question, if it does for speed and bandwidth reasons it will return the answer it has cached. TTL of 24 hours is saying ~if this cached record is less than 24 hours old then it is the answer, otherwise make a query to an upstream DNS server for a newer record.~ In modern times, this upstream query will often go directly to the authoritative nameserver, but it could end up with some other nameservers cached answer--again this is getting way beyond the scope of your question-but the complication is it can extend the cache time if the nameserver is not properly configured to assume the remaining TTL in the upstream cache that responded.)

Conclusions: making a change to an existing A-record will generally become available from all DNS servers worldwide in the next 86400 seconds (24 hours), if an more direct answer is needed lookup the authoritative servers for the domain and make your nslookup or dig query using one of them. (in advanced cases sub-domains can actually have their own ~differnt-than-the-main-domain~ authoritative nameservers, again tho beyond the scope.)

whatsmydns.net is a tool that you can use to watch the propagation or how fast your DNS change is occurring around the world. The green Checks and red X's are showing various DNS servers answer as compared to the authoritative answer. Remember that whatsmydns.net does not have every namesever in the world on it's map, so even all green checks could mean there are still servers with a cached record. Using this tool you will discover NEW records propagte or more across the internet more quickly, a changed record might take TTL seconds to be seen remotely. We have to say "might" because it may actually be more or less, but probably less.

Bottom line: Without making additional changes to the A-record for A.wc.net wait out the TTL of 24 hours, and make your queries again, most answers should be correct by then.