DNS And Name Server Cutover

A while back, I’d written a post about one of my customers I’d help transition from one ISP (DSL.net) to another (Comcast) for Internet connectivity at their small office. After that was completed, I thought they would be in a position to cut ties with their old ISP and stop paying for services they no longer used.

As it turns out, they couldn’t do that, at least not right away. This was because DSL.net’s name servers were the ones registered for their domain. But surely the customer could cease paying for a DSL circuit they weren’t using anymore, and then just pay them the measly amount to continue using their name servers and DNS. No dice. DSL.net’s position was that the two services were bundled together, you couldn’t have one without paying for the other. That’s just bizarre. So it became clear I would need to register new name servers and use somebody else’s DNS.

My customer’s domain registrar of record was domain.com. They had DNS management options for their customers, so I decided it made total sense to just setup the DNS records there, and then re-point the domain to their name servers. So I set a plan in motion to do just that.

Since these kinds of cutovers can impact pretty much all their services (e-mail, WWW, etc), I am always a little jittery about executing them, despite the fact I’ve done more than several of them. It’s all in the planning. Plan well enough, and there should be little to no disruption in web site accessibility and e-mail delivery. Plan poorly, and you can cause all sorts of problems. I also had a secret weapon up my sleeves, one that would allow me to monitor the status of the DNS changes and of all the services they impact.

One of my planning decisions was to schedule the cutover at the beginning of the Memorial Day Weekend (the evening of Friday, May 23 to be precise). The reason was simple: if there were any problems that caused a disruption, impact to their business would be minimal given the holiday. I’d also planned a “back-out” option for the cutover, so that if I did run into problems, I could always quickly put things back the way they were while I figured out what went wrong. I typed up the battle plan well before the scheduled cutover date. Needless to say, I communicated the timing with the customer to make them aware of when things were happening. They were completely on board.

When Friday evening rolled around, I queued up some of my favorite playlists in iTunes and started things in motion. I first logged into their domain management account at domain.com and added the DNS management feature to their services. Once that was added, I pulled it up and added the key DNS records that would need to be in place once to ensure everything worked (A Records, MX, etc). I let that simmer for a couple of hours while I occupied myself with some other tasks. Keep in mind, there is an oft-quoted timeframe of 24-72 hours for DNS changes to propagate across all the various Root Name Servers used throughout the world. But I figured since I was re-pointing the name servers to those belonging to the domain registrar, we’d start to see changes much sooner. Once I let those newly set DNS record changes simmer, I took the proverbial leap and updated the Name Servers for the domain to stop to pointing DSL.net’s name servers and now point to domain.com’s name servers.

After a few deep breaths, I brought my secret weapon to bear, namely the DNSreport function of DNSStuff.com’s professional toolset. As a matter of fact, I’d run a DNSreport well in advance of the cutover because it provided valuable information on how original DNS configuration. It didn’t take very long to start seeing the name server update come up in the results of the DNSreport. I had a command window running in the background, and I made sure their web site was responding to PING commands, which it was. The DNSreport results indicated that the critical DNS records were what they should be. Everything looked like it was going smoothly (mental note: I need to work on my habit of thinking things going well is just that, and not always a sign that the wheels are about to fall off). I performed some e-mail tests to ensure sending and receiving e-mails via their hosted Exchange server was still working fine, which it was.

I sent out a note to my customer informing them that the changes were successfully completed and that they could contact DSL.net at their leisure to close out their account. Finally, they could stop getting billed for services they no longer needed.

Ah, the sweet smell of success!