Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I set up a new DNS entry for one of my subdomains (I haven't set up any Apache virtual hosts or anything like that yet). How can I check that the DNS information has propagated?

I assumed that I could simply ping my.subdomain.com and assume that if it could resolve, it would show the IP address I specified in the A record. However, I don't know if I am assuming correctly. What is the best way to check this information?

share|improve this question
3  
Not a dumb question. It's not that straight forward to find out this kind of thing. –  aseq Apr 28 '12 at 1:27
1  
I agree with @aseq that this is not a dumb question, but "try it and see" would have given you the answer too. It's also something Google could answer just as easily with the littlest bit of effort (search for How to test if DNS information has propagated -- the bloody question title generates good Google results). –  voretaq7 Apr 28 '12 at 1:32
4  
I don't think you wasted people's time. Your question provoked some valuable responses. You never know how a seemingly simple question that could "just be googled" may turn out. One of the values of this forum is that the answers and questions can be expanded upon very easily. –  aseq Apr 28 '12 at 8:47
1  
@andrew nothing wrong with asking what a lot of us view as simple questions - this will probably be the top google result for that string in a few days because of how the site gets indexed/ranked. In general though Google is a better (faster) place to look: If Google doesn't know then ask here (and Google will learn) :-) –  voretaq7 Apr 28 '12 at 21:16
1  
I figured out why nothing I was trying was working. Apparently, our network is configured in a way that a new subdomain must be added in our local DNS too. So the subdomain was accessible from the outside world, just not in our network where I was testing. =[ But using nslookup and dig while specifying an external server made it so I could verify the external DNS information. –  Andrew Apr 30 '12 at 15:05
show 2 more comments

5 Answers 5

up vote 13 down vote accepted

You can use dig or nslookup, say your (or your provider's if you don't run your own) nameserver is ns1.example.com.

Using nslookup:

nslookup - ns1.example.com

At prompt type:

my.example.com

If it resolves to what you expected then it works. It should give you something like:

Name:   example.com
Address: 192.0.43.10

It may still take a while to propagate to the rest of the internet, that's out of your control.

Using dig:

dig@ns1.example.com my.example.com

You should see something like:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

Just using ping may give you an idea, but only when it has propagated (cached by remote nameservers may be a better way to describe it) and your local dns cache may need to be flushed. Although in your case this does not apply because this is a new record. In that case it should be available immediately. The above way is more precise in giving you an idea as opposed to just pinging it.

If you use windows then the commands and syntax may differ slightly, but are pretty similar.

share|improve this answer
3  
+1 If you're doing anything with DNS, get a copy of dig (*nix systems already have it, there are various versions for Windows available). –  Chris S Apr 28 '12 at 1:34
2  
-1. I'm sorry. I truly am, but this answer "propagates" the myth that DNS records propagate, which they most certainly DO NOT. The term you're looking for is "caching" which is what happens with DNS records, based on the TTL of the record. As the OP is referring to a new DNS record, no caching can have occurred, therefore any DNS client seeking to resolve the record in question will get the answer... immediately... since it can't have been cached by that client... or that clients DNS server... or any other DNS server. DNS records don't propagate to "the rest of the internet". –  joeqwerty Apr 28 '12 at 2:11
1  
joeqwerty's absolutely correct. dns servers will cache a positive or negative hit for a predefined time. However, in addition to the original post, there are several public name servers you can check against including the old GTE (4.2.2.1, 4.2.2.2, 4.2.2.3, and 4.2.2.4) and google (8.8.8.8, 8.8.4.4). Simple rule of thumb, new changes can take up to the duration of the ttl for positive or negative hit. However, there are instances where apps implement bad logic and cache answers for a longer period of time. –  bangdang Apr 28 '12 at 3:56
2  
I don't think you really have to stick to the exact definition to get a point across. Besides I think that propagating is not a bad word to use. It does cover the subject in the sense that the caching of the DNS record does spread out to a wider range of servers. That spreading out is what propagating refers to. I updated my answer to reflect the fact a new record is available immediately. –  aseq Apr 28 '12 at 8:36
1  
@aseq, it's a misleading term. And it mostly turns out that ppl who think/talk about DNS as kinda "propagation" do not know how DNS works. They usually states a crap like "it takes 2—3 days your DNS information to be propagated across Internet/Earth", and so on. –  poige May 1 '12 at 1:55
show 1 more comment

You can't test for DNS record propagation because DNS propagation doesn't occur. What you can test for is whether or not a DNS client or server has a particular DNS record cached.

Since this is a new DNS record, no caching can have occured. Assuming that your name servers are correctly registered at the parent servers and that your name servers are working correctly, this DNS record should be available immediately to any and every DNS client or server.

share|improve this answer
    
Good to know. Thanks! –  Andrew Apr 28 '12 at 4:14
    
Glad to help... –  joeqwerty Apr 28 '12 at 4:23
    
Is there any way to check that I entered a valid IP? I just wanted to be sure the IP address I used was the right one. Someone I talked to seemed to think that ping would fail if I didn't have an Apache VHost set up yet. –  Andrew Apr 28 '12 at 4:55
    
Ping isn't a DNS testing tool. Dig and Nslookup are DNS testing tools. Use Dig or Nslookup to test the new DNS record. Query for the record against your name server and then query for the record against other name servers to make sure they're finding your name server and that your name server responds with the correct answer. –  joeqwerty Apr 28 '12 at 13:33
    
"propagation" is a notion made up in case people cannot understand the actual situation, which is cache aging and expiration. What was needed to be said by DNS providers is "your data may not be seen until after XX hours". An explanation of why was needed so it would not look like the DNS provider was the delay. Too many people "cannot handle the truth". The made up "propagation" is an effective cover story. True DNS geeks know what really happens because they read the technical details. –  Skaperen Aug 22 '12 at 18:54
show 1 more comment

While the other answers are pretty good, remember that what's propagated to you may not be propagated to me. rather than using DIG or NSlookup and spending an hour checking DNS servers around the world, I usually use http://www.whatsmydns.net/ to see how the propagation is going.

share|improve this answer
    
There's no propagation in DNS, this term is rather misleading for all kind of lamers who won't find themselves reading RFCs, so don't <strike>propagate</strike> use this term, please. ;-D –  poige Apr 28 '12 at 11:16
1  
Of course there is propagation in DNS the RFCs presume that the reader understands that information can propagate as servers perform lookups and cache. it's particularly obvious when lamers read RFCs then wonder why a record on their server doesn't match the results of a lookup from a different server. They discover that propagate has the definition of "to spread widely" (which is exactly what needs to be checked - the distribution of updated records) –  Jim B Apr 30 '12 at 18:09
    
Neither distribution, nor propagation (except master to slave). –  poige May 1 '12 at 1:51
    
It's probably a relic from when it took sometimes close to a day to get changes made in .com domains loaded on the root nameservers (way back when .com was on the roots!) –  Cakemox May 1 '12 at 8:40
    
@poige- thanks for verifying your lack of understanding how DNS caching works. I would suggest reading the RFCs on how DNS works and perhaps checking the website I linked to for real world examples. –  Jim B May 2 '12 at 1:58
add comment

The easiest way to make sure your authoritative DNS servers in your delegation path are answering correctly is to use dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

This will follow the delegations to the nameservers authoritative for your query. The last answer is normally the one you are most concerned about, but the trace is helpful in that it will show who is answering for each delegation. If you are changing nameservers, though, this can be very useful.

Keep in mind that trace will query the authoritative servers directly, so there is no caching. This is the best indication that the answers are being returned as expected, but it is not a good indication of what end-users might experience. However, since you do not often have control over other peoples' caching nameservers anyway (beyond having the foresight to lower your TTL, wait the original TTL, making the change, then restoring the TTL), it's not usually worth checking after the fact.

share|improve this answer
add comment

Try check-host.net:

http://check-host.net/check-dns?host=example.com%20

The site lets you perform DNS queries through multiple public DNS servers in parallel. Super handy.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.