4

I am currently in the process of transferring a legacy website (from a legacy hosting service provider) to a modern solution. Due to my context-specific requirements (which include financial constraints), I made the decision to backup and replicate the website on a Digitalocean droplet (a virtualized linux instance) which has a static IP address 104.131.187.206. I have already configured everything appropriately, cleaned up the various loose ends that come from duplicating a Web application that is tightly coupled to its system, etc and the duplicate website is working perfectly fine.

Now, my goal is to point the existing domain name mcbc.on.ca to the new duplicate website on the DO droplet. The IP address of the legacy (shared) hosting provider is 216.251.32.98. Obviously mcbc.on.ca has been pointing to this address all this time. What I want is for mcbc.on.ca to point to 104.131.187.206. Furthermore, I am still using the legacy hosting provider for DNS and nameserver.

My task should be straightforward - simply modify the existing A entry for mcbc.on.ca in the Zone file so that it now points to 104.131.187.206. Now, I also wanted to keep an existing reference to the original website, so I added a new A entry for original.mcbc.on.ca that points to 216.251.32.98.

I successfully completed all of this yesterday and my DNS change has successfully propagated as of now (verified using this tool). FYI, it has been approximately 12 hours since I made the change.

My problem: For some strange reason, whenever I access the website at mcbc.on.ca, it sometimes resolves to the OLD address 216.251.32.98, and some other times correctly resolves to 104.131.187.206. I'd say the frequency is about 40% for the old address and 60% for the new address. This is obviously a problem.

Considering the fact that I've waited a good amount of time (although I understand that 12 hours is certainly less than 48 hours), as well as the fact that the tool I mentioned above shows that the DNS record has propagated to ALL over the world, my suspicion is that my home Internet ISP provider has a stale DNS cache.

My question: Am I right? If not, what do you think is my problem?

dvijayak
  • 43
  • 3
  • [Please don't use other people's IP addresses. Also, you will probably need to disclose the actual domain name/IP addresses.](http://meta.serverfault.com/q/963/126632) – Michael Hampton Oct 25 '14 at 19:13
  • @MichaelHampton My goodness, I'm so sorry. I thought those were non-sensical addresses. I apologize! (next time, I'll run my addresses through an evaluator and make sure they don't exist...) As for disclosing the actual details, since you're a Moderator, I'll heed your advice. Thanks for your moderation - I appreciate it. Definitely do not want to put actual irrelevant addresses here. – dvijayak Oct 25 '14 at 19:19

2 Answers2

5

DNS doesn't, properly speaking, propagate. Records have a TTL (time to live), and that's how long other caching DNS servers should retain an existing lookup answer. You'll want to do some more self-education rather than go by thumbnail rules like "12 hours should do it."

If the authoritative nameserver is showing the correct results, that's the end of the story. Since at least some (as you say, most) other nameservers are showing the updated answer, you're done. You've done what you need to do, and in fact almost everything you can do.

(It's often a good idea to lower your TTL long in advance of an anticipated change, and you don't say if you did that, or what the TTL was to begin with. And since you didn't give actual details, we can't check.)

/Edit - now that we can see your TTL, it's set to 1 day. Presuming the TTL wasn't recently changed to that value, that means that anyone with the old record would have kept it for at least 24 hours after receiving that answer. The requestor (most often other DNS servers) would not re-query to see any change you made in the following 24 hours. In your case, at least 24 hours prior to the change, you should have dropped the TTL to the lower value your DNS provider allows.

If your home PC's upstream DNS provider doesn't respect TTLs, use a different one, and make sure your local cache has been cleared.

mfinni
  • 36,144
  • 4
  • 53
  • 86
  • 1
    @dvijayak Your TTL appears to be 86400 (seconds, or 24 hours). So if it's only been 12 hours, then you still probably need to wait. – Michael Hampton Oct 25 '14 at 19:29
  • @mfinni Ah, thanks for the clarification. I will admit that my knowledge of DNS is quite rudimentary - I hope to fix that some time. I actually do not have access to changing TTL with my existing provider so I definitely didn't lower it indeed. So it seems that it is indeed the TTL. In that case, I'll have to wait. – dvijayak Oct 25 '14 at 19:31
  • In which case, get a new DNS provider. That's ridiculous, if it's true. – mfinni Oct 25 '14 at 19:32
  • @mfinni Fear not, that is precisely one of the reasons I'm doing this silly duplicating of the website. We are changing providers (contract with existing provider expires in a few weeks). But in the mean time, I have to do this, among other things, to give the illusion that nothing really happened. ;) Also, for the sake of my understanding, would you mind explaining me why some times the DNS indeed does resolve correctly? – dvijayak Oct 25 '14 at 19:35
  • 1
    Without you showing an actual DNS trace, I can only guess. It could be that your home ISP has multiple DNS servers (itself or upstream), and they had different ages on the record, so some of them have aged out and had to look up the new value, and others are still within the TTL (or whatever max lifetime they use, if they don't respect the TTL.) – mfinni Oct 25 '14 at 19:37
  • For the future, learn how to use *dig* for DNS queries, and make a point to put actual diagnostics into your questions. – mfinni Oct 25 '14 at 19:38
  • @mfinni Will do. Thanks for teaching me something new today :) – dvijayak Oct 25 '14 at 19:39
0

I know this is a very old question, but the this answer might be of help to someone who stumbles upon this very question, as I did:

Sometimes locally stored DNS can be an issue and it's hard to know . So here are two ways to check:

  1. Use a VPN (Opera browser has a free built in one) to check if the site is loading correctly. When accessed via the VPN, you can "choose" from which location you load the site.

  2. Change your windows Hosts file to add the IP address of the new server you want to access. By updating the Hosts file, you can be sure what you are looking at is the actual server you were wanting to see.