Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i am having a problem with my dns.

Like a week ago or more, i moved from ********** to hostgator, so i had to change the dns at my domain registrar (nic.ar)

I started the dns change process, when it was over, i was able to reach the page at the new server, it worked well for a few days, but then mysteriously, when i tried to reach it, the previous host error page appeared!, As if the dns changing process was rolled back or something :/. But at my registrar, the dns were shown well.

So I started the process again, to see if i could fix it. And again, i was able to reach the page at the new server at least; And I am still able to, but some friends of mine told me that they reach the previous host error page again.

Now, the curious thing is this, if I check at http://www.whatsmydns.net/, the result are these: (174.122.148.7 = hostgator, 184.82.98.172 = previous host

Denver CO, United States (Speakeasy)    174.122.148.7   
Reston VA, United States (Sprint)   174.122.148.7   
Orlando FL, United States (@quasar) 174.122.148.7   
Atlanta GA, United States (Bellsouth)   174.122.148.7   
Canoga Park CA, United States (Sprint)  174.122.148.7   
Seattle WA, United States (Speakeasy)   174.122.148.7   
London, United Kingdom (BT Global)  174.122.148.7   
Paris, France (Kaptech) 174.122.148.7   
Rome, Italy (Telecom Italia)    174.122.148.7   
Moscow, Russia (Petersburg Internet)    174.122.148.7   
Istanbul, Turkey (TTNET)    174.122.148.7   
Nurnberg, Germany (Hetzner Online)  174.122.148.7   
Hong Kong, China (PCCW) 174.122.148.7   
Melbourne VIC, Australia (Optus)    174.122.148.7   
Sydney NSW, Australia (Exetel)  174.122.148.7   
Auckland, New Zealand (Xtra)    174.122.148.7   

But if i check again...

Denver CO, United States (Speakeasy)    174.122.148.7   
Reston VA, United States (Sprint)   174.122.148.7   
Orlando FL, United States (@quasar) 174.122.148.7   
Atlanta GA, United States (Bellsouth)   184.82.98.172   
Canoga Park CA, United States (Sprint)  184.82.98.172   
Seattle WA, United States (Speakeasy)   174.122.148.7   
London, United Kingdom (BT Global)  174.122.148.7   
Paris, France (Kaptech) 174.122.148.7   
Rome, Italy (Telecom Italia)    174.122.148.7   
Moscow, Russia (Petersburg Internet)    174.122.148.7   
Istanbul, Turkey (TTNET)    174.122.148.7   
Nurnberg, Germany (Hetzner Online)  174.122.148.7   
Hong Kong, China (PCCW) 174.122.148.7   
Melbourne VIC, Australia (Optus)    174.122.148.7   
Sydney NSW, Australia (Exetel)  174.122.148.7   
Auckland, New Zealand (Xtra)    184.82.98.172   

and it keeps showing different results every time I check. It's like it goes back and forth, reaching new ip, and old ip.

share|improve this question
    
How many hours ago did you first change this?? – Arenstar Nov 17 '10 at 0:30
1  
How desperate are you... :P Answer us so we can help.. hehe – Arenstar Nov 17 '10 at 2:17
3  
I don't see your domaain in your question, so I can't check DNS here. – BillThor Nov 17 '10 at 2:18
    
Most likely you have two NS records for the domain and both name servers return different values. If you add actual domain name to the question then we can dig/nslookup and respond appropriately. – Saurabh Barjatiya Nov 17 '10 at 3:26

Behavior is what I would expect if you had a mix of old and new nameservers specified at your registrar. Nameservers usually rotate on each request.

Try checking what the root servers respond with. On Linux, host -a yourdomain.com. j.gltd-servers.net. will show the data for yourdomain.com.

The number in the response lines is the time (in seconds) the response will be considered valid by DNS servers your users may be using. Expect changes to take this long to propagate fully. It can be weeks. Unfortunately, your most frequent users are most likely to get old data.

This time is controlled by your nameserver configuration. Changes need to be planned at least one cache period in advance. The cache period should be reduced prior to the change, and increased afterwards. It can be increased afterwards, once you are sure the change is correct,

share|improve this answer
    
This can also happen if the NS records on the DNS servers themselves have not changed. The registrar provided glue will be used initially, but once the glue TTL expires it's anyone's game. – Andrew B Jan 5 at 5:43

I know it's an old question, but I just had this same problem, and the solution was super easy

If the timestamp of your DNS SOA record on the old host is higher than the timestamp of the DNS SOA record on the new host, it will bounce back and forth.

As soon as I changed the timestamp for my DNS SOA record on my new server, to be higher than the timestamp on the old server, the changes started to propagate correctly, and the changes "stuck" instead of bouncing back and forth like they were doing all day.

share|improve this answer
    
What do you mean by serial number - I don't think there is one is there? – dodgy_coder Dec 31 '15 at 13:15
    
Sorry, wrong terminology. It's actually a timestamp I was referring to. I updated my answer to use the right term. – Sherwin Flight Jan 5 at 5:36
    
@SherwinFlight If you are talking about the SOA SERIAL field, then serial number would be the correct terminology. However, this will matter for zone transfers between a master and slaves, not if you are changing the delegation altogether. – Håkan Lindqvist Jan 5 at 9:23

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.