Take the 2-minute tour ×

I just transfered a domain from one host and registrar to another. 48 hours later the site is still down. How do I know if I should just keep waiting or if there is a problem?

UPDATE: nslookup says it's a NXDOMAIN (non-existant?) - what does that mean?


In the transfer godaddy had set the wrong name server - a quick phonecall rectified this.

Thanks for all your answers - I have learnt a lot!

share|improve this question
Do you know what the DNS entry's 'Time To Live' (TTL) is? –  Chopper3 Jun 1 '09 at 15:34
This should really be "Nameserver change" or "registrar change" - not "DNS Update" –  Mez Jun 1 '09 at 21:00
add comment

5 Answers

up vote 9 down vote accepted

There are a couple of tools you can use to help you see if things are configured correctly. There are web front ends available for them but I am more familiar with command line variants so that is how I will describe them below.

Check with whois where the domain is currently hosted

To get the information for this site you would use the command "whois serverfault.com"

This gives the response (trimmed for brevity):

   Registrar: GODADDY.COM, INC.
   Whois Server: whois.godaddy.com
   Referral URL: http://registrar.godaddy.com

This information shows the information that the builders of the .com zone file (internic) hold. It also shows that further information is available from the Godaddy whois server.

If this output does not show your new Registrar and name servers the transfer is not yet complete and you should contact your old registrar.

If this shows your new registrar but not the correct dns information the transfer has been done wrong and you should contact your new registrar.

If the details are correct but the site isn't working then either the .com top level zone has not yet been updated and you need to wait, or the new name servers are not set up correctly. To find out which use the command "dig"

First check the GTLD servers (authoritive for .com):

"dig ns @a.gtld-servers.net serverfault.com"

The results give:

;serverfault.com.   	IN	NS

serverfault.com.    172800	IN	NS	ns21.domaincontrol.com.
serverfault.com.    172800	IN	NS	ns22.domaincontrol.com.

ns21.domaincontrol.com. 172800	IN	A
ns22.domaincontrol.com. 172800	IN	A

If this information is correct you can continue to do the same query against your new providers DNS:

"dig ns @ns21.domaincontrol.com serverfault.com"

;serverfault.com.   	IN	NS

serverfault.com.    3600	IN	NS	ns21.domaincontrol.com.
serverfault.com.    3600	IN	NS	ns22.domaincontrol.com.

;; Query time: 76 msec
;; WHEN: Mon Jun  1 16:47:51 2009
;; MSG SIZE  rcvd: 85

If this is showing the correct information then you likely have a caching problem and will need to wait for old entries held on caching name servers to expire.

share|improve this answer
dig doesn't return an answer section for the domain! –  user7157 Jun 1 '09 at 15:56
Which dig has no answer section? a.gtld-servers.net, the authoritive server for your new registrar, or your local resolving name server? If 1, and the whois lists your new registrar then ask the new registrar to check. Likewise if 2, also contact your new registrar. If 3 you may have a negative cache result which you will either need to wait to expire or flush the server cache ("rndc flush" on bind) –  Russell Heilling Jun 1 '09 at 16:05
add comment

First you need to check the dns servers for your domain:

  • whois domainname.com

If the dns servers are still your former dns servers then the transfer failed. If everything is ok, the next step is check the dns records in your new dns servers:

  • dig @dns.domainservers.com domainname.com
  • dig @dns.domainservers.com www.domainname.com

You need to get a result like:

  • www.domainname.com. 86400 IN A A.B.C.D

Where A.B.C.D will be the IP address of the server where you're hosting your site. If that is incorrect you need to check your domain records.

Finally you can try with other dns servers like opendns to check if your domain is updated in the world:

  • dig @resolver1.opendns.com domainname.com

I think the problem is in step two, maybe you forgot to add the records in your new dns servers.

share|improve this answer
+1 for the troubleshooting guide .. check if domain registration was moved, then check DNS where registration is pointing. –  tomjedrz Jun 1 '09 at 16:15
add comment

I would check with various DNS servers. You can use a tool like nslookup or dig to point directly at a specific DNS server. Start with hosting company's server, then try the ones at your work, from your ISP, your friend's work, etc.

share|improve this answer
add comment

I would follow these steps first:

  1. Query whois to check which DNS servers are to be used for your domain.

    whois domainname.com

  2. Then check these servers are returning results:

    dig A myhost.domainname.com @my.dnsserver.net

Do this for all of the dns servers listed in the whois changing the @dnsserver.

share|improve this answer
add comment

What happens when you transfer domains between registrars is up to regulations for the TLD or Registry, it might just be that your new registrar is not in possession of the old DNS records anymore and in that case you might want to seed them with new ones. 48 hours is already a long time to be 'off the internet' so i would not hesitate to contact your new hoster/registrar.

following up on Russell's answer:

"dig soa serverfault.com @ns21.domaincontrol.com"

serverfault.com.        86400   IN      SOA     ns21.domaincontrol.com. dns.jomax.net. 2009031400 28800 7200 604800 86400

"dig soa serverfault.com @ns22.domaincontrol.com"


The first Number after dns.jomax.net is the Zones Serial Number, quite commonly a date with an added serial for the number of changes that day, it's usually a bad sign if these are out of sync.

You can also check for your new record directly, say we changed www.serverfault.com recently:

"dig a www.serverfault.com @ns22.domaincontrol.com +norec"

www.serverfault.com.    3600    IN      CNAME   serverfault.com.
serverfault.com.        3600    IN      A

the +norec option disables the "recursion desired" bit in the question which is on by default. Authoritative Nameservers that are also caching might set you off with answers from their cache if you forget to specify +norec, this can be quite misleading at times.

share|improve this answer
add comment

Your Answer

