I just set up a second linode to test a new configuration without disrupting the sites on my 1st. My old linode is in Dallas, and my new is in Newark (I recently moved from TX to NY).

Nearly 2 hours ago, I deleted a domain zone in my DNS manager, and recreated it to point it at my new linode. At this time, if I run dig on my old node for the domain, it reports the new ip address. If I run dig on my new node, it still reports the old ip address.

Any idea why it hasn't updated on the new node yet?

Until this gets resolved, will there be any negative effect while setting up my server?


Thanks!

What was your old TTL set to on the record you are testing?

Changes to the Linode manager take effect every 15 minutes or so. If you want to specifically test that, make sure that you query the Linode servers directly, e.g., "dig @ns1.linode.com ...."

BTW, not sure if you just explained it wrong, but changing the address for a name shouldn't require you to delete a zone, just change the record in the existing zone.

However, any resolvers along the way that have queried your information prior to the change, will be able to cache it for the TTL set in the response. So for example, if you "dig some.domain" you are actually talking to your local resolver and potentially getting a cached response. That response will include the current TTL so you can tell approximately how long before the resolver will refresh its information.

However, what you can't necessarily tell is if there are any intermediate resolvers between the one you are talking to and the actual authoritative servers (Linode) so there be other intermediate points with a different remaining lifetime. This is less likely on your Linode itself than, say, at home where you might have a cache in your router versus your ISP.

I expect if you wait long enough you'll start seeing the new address, but it'll take some time for it to be globally visible. Until then you'll have people connecting to either the old or new host simultaneously.

In the future, if you are going to change an address, the first thing to do is drop the TTL value in your existing definition pretty low (say 60-300s), then wait long enough (based on the prior TTL value) for all caches to have the new value. At that point you know your change will roll out fairly quickly.

-- David

Thanks for your reply.

I did delete the zone and recreate it. I was deleting obsolete zones and accidentally deleted the one in question as well.

My TTL is set at the default.

As for resolvers along the way... I am actually running dig on the linodes (don't know if that was clear).

I ssh into my old linode, run dig on the domain name in question, and it returns the ip of my new linode.

I ssh into my new linode, run dig on the domain name in question, and it returns the ip of my old linode.

It's now been close to 3 hours since I made the changes in the DNS Manager, and I am still seeing the wrong ip when running dig from my new linode.

My domain name is working properly for browsing from my desktop. I've checked various DNS servers, and they all report the correct ip. It's just my new linode that doesn't seem to know the correct ip address.



Thanks.

I believe the default is 86400 seconds, which is 24 hours. Assuming that was the case (probably not absolutely possible to tell given the old domain was removed), you'll need to wait at least 24 hours before you can be sure anyone who previously used the name is receiving the new address. However, anyone who hadn't queried your name in the past 24 hours would get the new information immediately.


Can you post the exact command you are running. If you're actually querying the Linode DNS servers (e.g., "@ns#.linode.com") then getting different answers from the two clients definitely sounds unusual.


Did you perhaps query that name just before making the change? If so, it might be cached in the local resolver from just prior to the change. What is the TTL shown in the response? Can you post the actual dig command and output?

This is a case where seeing the actual domain involved would be helpful since that's really the only way to investigate what DNS queries are returning.

-- David

Sorry for not getting back to you on this until now. Things seem to have sorted themselves out at some point between my last post and when I got home from work today.


Thank you for your assistance.


C