Home / server / Questions / 383984
Accepted
Andrew
Asked: 2012-04-28 16:59:46 +0800 CST

How to test if DNS information has propagated?

  • 772

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?

domain-name-system

5 Answers

  1. Best Answer

    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:

    [email protected] 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.

    • 16

  2. 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.

    • 7

  3. 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.

    • 5

  4. 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.

    • 3

  5. 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.

    • 2