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.

Transferred domain registration for mysite.com to namecheap last week, without issue, but did not change DNS at that time. Approximately 12 hours ago, I attempted to switch DNS to namecheap nameservers (a "simple" operation through namecheap panel) and then created A records to point to a different IP address than where the domain had pointed previously.

Checking propagation via whatsmydns.com, all records show mysite.com pointing to the new IP address, indicating to me that namecheaps DNS servers are working properly.

What's strange is that I cannot access the domain via a browser at mysite.com, it times out here from my desktop in Chicago (as an RCN broadband subscriber); "ping mysite.com" returns the old IP address and hangs, which is not a "correct" result vs. my expectations.

However, if I "curl mysite.com" while logged into servers at a NJ data center I get the expected response (and the output is the expected html ), and "ping mysite.com" looks correct showing the newly updated IP address that I'd expect. Lastly, if I ssh into the uChicago network and run ping or curl, I get the "proper"/expected response.

So, I'm thinking this is a classic DNS propagation issue. I know it's only been 12 hours, but I'm woefully inexperienced re:DNS and am now wondering if there's something I missed.

I'm content to wait it out a bit, but that's a little careless. So hopefully I've provided enough clues that someone smarter than me can either confirm that it looks like a DNS propagation issue, or can otherwise point me towards more ways to test for possible errors. Thanks.

Edit: Investigating this a little further, here is the output from dig mysite.com @a.root-servers.net":

Edit 2: polynomial pointed out that I failed to leave a space before the @, which gave incorrect results. I've updated the queries and here are the new results.

; <<>> DiG 9.6-ESV-R4 <<>> mysite.com @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19132
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mysite.com.       IN      A

;; AUTHORITY SECTION:
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     172800  IN      A       192.5.6.30
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net.     172800  IN      A       192.33.14.30
b.gtld-servers.net.     172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net.     172800  IN      A       192.26.92.30
d.gtld-servers.net.     172800  IN      A       192.31.80.30
e.gtld-servers.net.     172800  IN      A       192.12.94.30
f.gtld-servers.net.     172800  IN      A       192.35.51.30
g.gtld-servers.net.     172800  IN      A       192.42.93.30
h.gtld-servers.net.     172800  IN      A       192.54.112.30
i.gtld-servers.net.     172800  IN      A       192.43.172.30
j.gtld-servers.net.     172800  IN      A       192.48.79.30
k.gtld-servers.net.     172800  IN      A       192.52.178.30

;; Query time: 3 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Fri Oct 14 01:04:16 2011
;; MSG SIZE  rcvd: 497

And then from "dig mysite.com @dns1.registrar-servers.com" (that's a namecheap dns server):

; <<>> DiG 9.6-ESV-R4 <<>> mysite.com @dns1.registrar-servers.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55527
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mysite.com.       IN      A

;; ANSWER SECTION:
mysite.com. 1800   IN      A       [IP ADDRESS THAT IS CORRECT]

;; Query time: 31 msec
;; SERVER: 69.16.244.25#53(69.16.244.25)
;; WHEN: Fri Oct 14 01:07:09 2011
;; MSG SIZE  rcvd: 57
share|improve this question
    
Did you remember to increase SOA serial number and change zone's NS records? –  raspi Oct 13 '11 at 20:50
    
1) I'm not sure I have the ability to edit SOA. 2) NS records were updated to point at the new nameservers. –  CLM Oct 13 '11 at 22:53
    
Did you remember to set the TTL to a low figure well before this move? While an ever increasing number of system ignore TTL none have a reason to refresh their cached data in less time than the TTL. –  John Gardeniers Oct 13 '11 at 23:11
2  
What's the actual domain name, so that we can help... –  joeqwerty Oct 13 '11 at 23:14
    
The default TTL on the DNS servers could well be 24 hours (this is the default on BIND) my guess is that this will all sort itself out in time –  Paul Willis Oct 14 '11 at 0:03

1 Answer 1

up vote 0 down vote accepted

This does sound exactly like a TTL issue. A couple points, before you made the actual switch you should have lowered the TTL. Usually the DNS TTL for sites can be high so you reduce the number of DNS requests. However it is good practice to reduce the value a few days before you need to make the change.

To diagnose this you just need to find the TTL you are currently waiting for from your nameserver. You can also query some other popular resolvers to see what other people might be seeing. Here is the dig command:

for i in 4.2.2.1 google-public-dns-a.google.com 10.4.1.11
do
  echo $i
  dig bo.lt @$i | grep ^bo.lt
done                                 
4.2.2.1
bo.lt.                  43200   IN      A       199.204.81.1
google-public-dns-a.google.com
bo.lt.                  49643   IN      A       199.204.80.1
10.4.1.11
bo.lt.                  81226   IN      A       199.204.81.1

This shows that for the domain bo.lt GTEI has 43,000 seconds left on its record, google has 49k and my local nameserver has 81,226 seconds.

share|improve this answer
    
nice script, i'd vote it up if I could. I have 1588 seconds left based upon this script. Hoping everything is fine thereafter. –  CLM Oct 14 '11 at 5:21

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.