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 can't find A.wc.net: NXDOMAIN

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

@HomeMac (~ (BARE:master)): nslookup A.wc.net

Non-authoritative answer:
Name:   A.wc.net
Address:  (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

;A.wc.net.                IN      A

A.wc.net. 86400   IN      A  (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?

  • 1
    It looks like TTL is 86400 seconds or 24 hours. This means changes to the IP address in the A record can take up to 24 hours to propagate to other nameservers.
    – Tyson
    Oct 30, 2015 at 5:09
  • Thanks for noticing that and commenting. If it's TTL on the nameservers then why does nslookup from another host work, but not on the host in question? And why does dig get the right answer, but nslookup fail? I'm trying to understand the underlying mechanism, without having been well trained in system administration.
    – Rich
    Oct 30, 2015 at 14:40
  • Nameservers are made to cache records they have looked up until TTL expires. In your first example using nslookup was called without a specified Nameserver, so it choose and told you it was choosing a Nameserver at to do its lookup, that server had no info. I example 2 Google Nameserver already knew the new answer, in example 3 you specified to use linodes Nameserver. Had you done that in example 1 with nslookup you would have gotten the correct answer. The thing to remember is nameservers don't all get the new record at the same time.. In fact with TTL @24hours,
    – Tyson
    Oct 30, 2015 at 14:56
  • 1
    that's how long it will take globally. Use the map at whatsmydns.net to watch and better understand propagation.
    – Tyson
    Oct 30, 2015 at 14:59
  • Sir that comment is looking more like an answer than a comment. If you submit as an answer then I can and will mark it as such; if not, I believe I cannot. Thanks.
    – Rich
    Oct 30, 2015 at 15:07

1 Answer 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 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 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.

  • That whatsmydns looks like a very nifty tool. :-)
    – djvg
    Jan 12 at 12:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .