Hi Joe,
I'm slowly getting there with the DNS :-) Here's my situation... I have one production server and one development server. They are in separate locations, same setup with Virtualmin. I have the dev server set as the secondary DNS which seems to be working ok (I can see green zones matching master). My primary DNS server is also my web server. In the event of my ns1 going down, the secondary DNS is not much good to me cause it points to the web server that would be down (bear in mind I'm not that interested in email - hard to believe I know! Our organisation uses Lotus Notes :-( hehe)
What I would like to do is mirror the website files from production server to dev server (not asking you for how to on this). In the event of the web server (and ns1) going down (for too long to have offline), I'd like to be able to change the ns1 IP address to point to dev server. Now if all my web files are up to date, I'm halfway there. But the problem is the DNS records will be pointing to the IP of production server which is down.
Is there a way of transferring the DNS records to the dev server but having the IP addresses point to the dev server's IP?
Hey Jeremy,
No, but you'd be cruisin' for a bruisin' if you opted to go that route. DNS is a heavily cached protocol...by the time the new records propagated to everyone, your primary would be back up and running (hopefully). It would also be a quite intermittent experience for users--your secondary may also be used even when the primary is not down, so you'd be sending users to the backup system sometimes and without predictability.
The ideal failover mechanism is IP takeover, but being in separate locations (which is also ideal for failover...go figure, everything has tradeoffs) means they can't do that unless you also have control over some of the routing infrastructure involved (most people don't).
Failover is a pretty difficult set of problems, but there are a few "poor man's" solutions that'll do in a pinch. And, your DNS idea will do the trick if you've got no other option. But you can't have those records always "ready" with alternate IP addresses, for the reasons above.
What you can do, in the event of an emergency, is use the Convert to Master button in the BIND module on the slave. Then you can update the IP addresses (either via sed from the command line, or via a few clicks in the Webmin module--or you could prepare, in advance, a batch file for the updated zones, and dump it in when you need it), and run from the secondary until sanity returns. You'll still get a lot of users that can't find you, but after about 24 hours that number drops pretty low.
--
Check out the forum guidelines!
I meant to say that it was a "poor mans" idea! Thanks for the info.
What if my ns1 and ns2 were on the production web server... I then set up dev server exactly the same (but no ns pointing to it).
In the event of an emergency, I then change the IP of ns1 and ns2 at my registrar to point to dev server. Arn't the ns changes maintained by the registrar propagated really quickly? Or am I still crusin for a bruisin?
Hey Jeremy,
Nothing about DNS is fast except the common case (making a request for a domain that is working right--this case is actually quite amazingly fast, usually), and changes at the registrar are usually slowest of all. There are at least two threads here in the Virtualmin forums where folks tried the registrar switcheroo, proclaimed immediate success (or success after the ~4 hour delay most registrars take to update their records), but then found that for three days or so, things didn't work for all users.
There are things you can do to make DNS changes propagate faster (shorter TTL for records), but then you make service to your website slower in the common case. And not all ISPs respect short TTLs (because TTLs do get abused out there, and they assume that most of them aren't actually changing as frequently as the TTL claims).
No, you're better off with your first idea (but not making the changes on the secondary until after the problem on primary occurs). It'll work for a good percentage of people within a few minutes of the change, and a few hours for a large majority, and two or three days for the unlucky few, and it won't break the common case in any way.
There's a reason why the big scalability and redundancy solutions (I use "solution" here in its original meaning, not to indicate there is some off-the-shelf component that'll solve these problems in a generic way) cost a lot of money. I like doing things on the cheap, too, but there are tradeoffs and limitations. If you control your routers, and your subnets, you can have always-on reliability. Or, if you put two servers on the same network segment in a really, really, safe place ("safe" meaning: good power backup systems which very few hosting providers have, good climate control, good security, location outside of the common path of earthquakes and hurricanes and tornadoes and snow storms, and good staff), you can use IP takeover, which can provide failover time measured in seconds.
--
Check out the forum guidelines!