|Emergency situation in changing hosts|
Host says it can't point DNS outside its own system
| 1:08 am on Jun 25, 2004 (gmt 0)|
Last minute change in what I thought was a well-conceived plan to seamlessly move a site from one host to another.... Need advice ASAP.
Site is currently at Host A, which also hosts the DNS. :(
A duplicate of the site has been built at Host B, currently on a unique IP# account.
Plan was to point the A-Records from the Domain Name Server at Host A to the IP number account at Host B... wait over the weekend, if even that long (the TTL setting is 900 seconds)... and then on Monday have the registrar (in this case, Network Solutions), move the DNS from Host A back to Network Solutions, so we don't have to go through this again when changing web servers.
This way, during the DNS propagation, which Network Solutions says takes 24-72 hours, all queries for the site would either be going to through the Host A DNS, or through the Network Solutions DNS, both of which would point to Host B.
Unfortunately, per the client, who had set up the hosting arrangement with the first host, Host A is saying that "they are unable to point to anywhere outside their own system."
I'm not sure whether to believe this, actually... we're checking with the Host A management first thing tomorrow... but, if it's true, I can't figure out how to avoid loss of continuity (including inbound email, as the DNS server controls MX Records; client has separate mailserver).
My only thought is to have Network Solutions do the change over the weekend... ie, tomorrow... when the damage is likely to be least. Any thoughts, suggestions?
I'll be out part of this evening but back in a few hours, but will check in as soon as I get back. Just got hit with this.
| 1:33 am on Jun 25, 2004 (gmt 0)|
You could always use host B's nameservers, update the domain registration to specify B's nameservers as authoritative, and make your changes on B's nameservers instead of A's. Once it is set up, your domain can potentially resolve to one host or the other, and as long as you have a copy of the site on both hosts, it won't matter. Then ask Host A to nuke your DNS zone file on their system.
Nameservers need not have any relationship with your hosting -- you can use a nameserver at another host, or set one up on the PC in your den. The registrar points to the nameserver, the nameserver translates your domain name to an IP address, and the IP address locates your host and 'your site'. None of these services are necessarily co-located.
See if Host B is more cooperative/competent.
| 5:12 am on Jun 25, 2004 (gmt 0)|
When you register a domain anywhere - always find out if YOU have complete control over the zone files, and if THEY will serve as a parking server for the domain.
I never register with a host who insists on putting my domain on their name servers. That puts you at their mercy.
Go Daddy, and Verio will allow you to park your domains and manipulate your own zone files.
| 6:05 am on Jun 25, 2004 (gmt 0)|
|Nameservers need not have any relationship with your hosting |
That's what I thought, which is why I thought my original plan would work. I didn't choose Host A and hadn't been dealing with them.
|You could always use host B's nameservers, update the domain registration to specify B's nameservers as authoritative, and make your changes on B's nameservers instead of A's. |
Not sure I'm fully understanding, but I think I do, and it's brilliant if I'm understanding it right. ;)
Main objectives... to change web hosts... to avoid any service glitches while we do... and eventually to get the authoritative nameserver back to the registrar.
Let me just think through this out loud....
a) set up the DNS on Host B's nameserver so it points to our Host B webserver, and then have the registrar call Host B's DNS nameserver authoritative.
At that point, we have the site on two different host webservers, Host A and Host B, and one or the other will come up, depending on which nameserver a name query encounters.
Within a few days, the address of Host B's nameserver as the authoritative nameserver should propogate around the web.
b) eventually, allowing for some safety, we nuke Host B's zonefile, perhaps waiting long enough for Google's cached DNS to catch up with the registrar's DNS.
(Once we nuke the zonefile, does it make sense to keep the site up on Host A, since we're also losing our MX Record from Host A's DNS? How long does it make sense to keep the site and zonefile up, and can keeping it up lead to trouble?)
c) I assume then that we could safely move the primary nameserver back to the registrar. Everybody would get either Host-B's nameserver or the registrar's nameserver, both pointing to the site on Host-B.
Am I understanding this right?
d) How would I keep Host-B's nameservers set up as backup nameservers, something I've seen recommended, particularly as they're in different geographical locations from the registrar's nameservers.
|See if Host B is more cooperative/competent. |
Not sure what Host B would be doing that's special here, as the A-Records would be pointing to their webserver.
| 7:38 am on Jun 25, 2004 (gmt 0)|
Can't edit previous to correct...
|b) eventually, allowing for some safety, we nuke Host B's zonefile... |
- to read...
b) eventually, allowing for some safety, we nuke Host A's zonefile...
| 1:38 pm on Jun 25, 2004 (gmt 0)|
The alternate plan makes a lot more sense to me if we first point Host B's nameserver at the IP on Host A... establish it as the primary nameserver... and then point it at the Host B IP, change the primary nameserver back to the registrar, having it also point to the Host B IP, and nuke the zone records on Host A's nameserver.
Is this sounding better?
| 2:39 pm on Jun 25, 2004 (gmt 0)|
Your alternate plan seems too complicated to me. When changing hosts, I just make a duplicate website on host B, go to the registrar and tell them that host B's nameservers are now supposed to be used. Then I wait a few days without making changes. Then I forget about Host A and cancel the account at the end of the month.
| 2:53 pm on Jun 25, 2004 (gmt 0)|
... or you could skip using host B's nameservers altogether, and simply use the registrar's nameservers. This would save a step, reduce the chance for complications, errors, etc.
It sounds like you understand the process at this point, so either approach should work.
I'd also suggest getting opinions on these plans from your registrar and the host B staff if possible. I'd hate to have an error in something I wrote cause problems.
[added] stevenha beat me to it [/added]
| 2:25 am on Jun 26, 2004 (gmt 0)|
|It sounds like you understand the process at this point, so either approach should work. |
Well, sort of. Most understanding thanks to WebmasterWorld and to "DNS Oversimplified"....
It was frightening to discover, though, how much better I understood it than most tech support people I spoke to at the hosting companies (until I got up to the management level), as well as at our mailserver company, and my understanding is pretty wobbly. Network Solutions' tech support, I should add, was great.
It turns out that simply using the registrar's nameservers right off will work pretty much the same as my original plan (which was to repoint Host A's nameservers to Host B's webserver, and then to use the registrar's nameservers).
No matter who hosts the nameserver, there's a propagation period of 24-72 hours when you change nameserver locations. During this time, as best as I could discover, queries might go to either the old nameserver or the new one... OR, they might not get either.
With my original plan, I'd hoped that when requests went to the Host A nameserver, they'd get pointed to the webserver at Host B. Since... except for some capitalization in the index page title tag... the sites on Host A and Host B are identical, I'm not sure there really would have been any difference.
I don't think there's any way around the 24-72 hour propagation period when you do change nameservers, which is why I chose to move it back to the registrar (in this case, Network Solutions).
Per Network Solutions, subsequent hosting changes (which would not involved moving the nameservers) would take effect across the web in 2 to 3 hours. I suppose changing registrars might take longer, but I'm not sure whether the DNS location would have any effect on that at all.
Would value some input about backup nameservers. As I think I understand it, setting up backup nameservers is purely a registrar thing. Eg, if I put my A Records and MX records up on my host nameservers, I gather that wouldn't accomplish anything, and in fact would only introduce possibility for error.
Changes now about 8 hours old, and so far I'm still seeing only the site on Host A.
| 2:36 am on Jun 26, 2004 (gmt 0)|
I just changed nameservers last weekend (was WAY more complicated than needed to be, due to sheer stupidity - blond AND senior moment on my part); of course, due to that mega-idiocy evidenced by yours truly, I would have been REALLY HAPPY had the propagation taken the time generally postulated for the change (I'd have been thrilled with even the LOWER estimate!)
What actually happened was that the sites were showing up live on the new DNS within 7-8 hours. *sigh* My host postulated that the registrar was bored. It's as good an answer as any, I guess....
| 2:45 am on Jun 26, 2004 (gmt 0)|
> but I'm not sure whether the DNS location would have any effect on that
No, because there is no fixed location for DNS - it's a distributed system. The propagation time is the delay required to update every ISP's nameserver in the world... Pretty fast if you consider it in those terms. Having ISP's and corporations copy (cache) DNS info means that for the most part, DNS translation can be local, and therefore fast for most users. The proxy I run for my local (home) network has a DNS cache, and if I request DNS info for your site, it will get updated, too.
This distribution of DNS info is what gives meaning to "authoritative nameserver" -- the fact that DNS is distributed, but in cases where the DNS time-to-live (TTL) is expired or there is a conflict, the authoritative nameserver is the final arbiter of what info is correct.
So, referring to a DNS record's location is similar to asking where Google's "master index" is; it doesn't exist, because the index is copied to datacenters -- and the machines in those datacenters -- all over the world.
When you start noticing that "tech support" should be calling *you* for help, I think you're coming up to speed... ;)
I don't know about the backup nameservers, but I'd like to hear about it if you find out.
| 7:08 am on Jun 29, 2004 (gmt 0)|
An update to everyone on how this worked out. The DNS was moved from Host A to the registrar at about 11:30am PDT on Fri, June 25, pointing at Host B's webserver.
I saw nothing happening on Friday, but on first check Saturday morning, at 10:40am (about 23.5 hrs later), I was seeing the site on the new host (could tell by changed capitalization in the page title). I have several different ISPs, and on early Saturday I would sometimes see a different site returned via a different ISP.
On my main ISP, the site returned went back and forth a few times, every three hours or so... then stayed with the site on the new host. This pattern was also observed by others in California, who were watching on different ISPs.
This morning, on Monday June 28, at about 9:30am, I first saw the new site indexed in Google, with a fresh date of June 26. This afternoon, the fresh date changed to June 27.
The big worry I had, that the site would disappear for a while, apparently never happened. I always got one site or the other... and never got an error page. Ditto for everyone else who was checking. I will keep the old site up for a month or two in case anyone gets the old IP#.
As I've been thinking through the whole process, I'm not understanding the concern I've frequently seen expressed on the board about possible dupe content penalties if Google looks at an old DNS cache. Since Google's index is name based, I'm assuming Google will see one site or the other and think they're the same, not dupes. Anything I'm not getting here?
|When you start noticing that "tech support" should be calling *you* for help, I think you're coming up to speed... |
I've gotten some job offers, but they want me to move to Bombay. ;) Thanks.
| 7:59 am on Jul 6, 2004 (gmt 0)|
PS to above... new site just appeared in Yahoo. Not a report of a glitch or lost email or any interruptions.
| 9:32 am on Jul 6, 2004 (gmt 0)|
Robert ..for the future go here [zoneedit.com...] and you can do it all yourself at your leasure ...and it's free ...
Host A was lying ....
| 11:00 am on Jul 6, 2004 (gmt 0)|
"they are unable to point to anywhere outside their own system."
This is nonsense. They simply don't want to do that.
Other than that, if you're switching name servers at the same time anyway, the exact sequence doesn't matter. Both the name server designation and the actual domain resolution data will take time to propagate. This means that both changes will only be seen by everybody after a few days. Therefore you should simply do it in the sequence that is easiest to implement:
1. Configure your domain on the new DNS server (at your registrar or your new host).
2. Switch your domain to the new DNS server at the registrar.
3. Wait for the result to propagate.
4. Do whatever is appropriate with the old host.
Apparently this is exactly what you did. Good for you! :)