Moving from one ISP to another, along with new nameservers

Current ISP is closing it's doors.  They also host our DNS records(about 5 total...MX, A, SPF and SRV).  New ISP will have new circuits up this Friday, but it looks like they don't include hosting nameservers without paying extra, so I thought I'd just use my registrar( as our nameserver(s) and host the DNS records there for free.  Since my servers(email and VPN appliance) will now have new public IPs(both are Nat'd on the firewall), is there a way to seamlessly transfer over with no/minimal downtime?  
In a nutshell:

OLDISP hosts our MX record, autodiscover record, A record for VPN and SPF record.  All of these records are using public IP addresses provided by OLDISP. Currently, when I look up our nameservers on, they point to the nameservers hosted by OLDISP.

NEWISP has given me a new block of public IP addresses to use for my records. I would like to use to manage my records as well as be my new nameserver(s).

I can't figure out how to do this on a Friday afternoon with little to no downtime.....  Thanks for any advice/suggeastions.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Unfortunately there is no way to do this without downtime.  You have to move you name servers over to, once it is there, you have to manually create a new record for each entry.  You would think they would have this down by now, but alas it is still a manual process.  Usually, the main DNS servers will update within 30 mins to an hour, and the lesser ones within 4hrs.

Once you have done this, update your firewall config's and wait ...
tenoverAuthor Commented:
Thanks.  Would it make more sense to do this in steps, like so:

Have OLDISP(current nameserver host) update current records with the new public IP addresses.

Wait a week, then move nameservers from old ISP to

OLDISP is getting rid of their T! hosting services, but has offered to keep hosting DNS zone and FTP services if would like them to.....

Honestly it is six and half a dozen.  Either way you have to wait for replication to take place to update either your existing records, or your new ones.  And changing your name server update is replicated the same way.

You may save yourself a bit of time on the IP replication, BUT .. you would then have another set of possible downtime when you change your name server as the old Name servers delete your old records and your new replicates out your new.
Introducing the "443 Security Simplified" Podcast

This new podcast puts you inside the minds of leading white-hat hackers and security researchers. Hosts Marc Laliberte and Corey Nachreiner turn complex security concepts into easily understood and actionable insights on the latest cyber security headlines and trends.

tenoverAuthor Commented:
Is there any MORE downtime involved if I go with my original plan, which would be to do EVERYTHING at once(change over my nameservers AND change all the public IP/zone entries)??  Is there a preferred wokflow for this?

I ask because THIS  Friday, the new ISP will be coming out with a new router and turning on the circuit.  At that point, I need to know in what order I should do/have done things for minimal downtime.

- change nameservers
- update all entries on new name servers with new public IPs
- bring new router up
- change any firewall NAT settings and/or references to public IPs and DNS settings
- reboot firewall
Talk to and find out how long from when you pull your Name Servers over to them, you can create records.  Between this and replication it your downtime.  usually it is instant.

For your DNS

Move your name servers
Create your old records
Sit and wait.

For your new circuit:

Bring up your new router and test connectivity and stability.
Once you have signed off on the new circuit, either change your current config (or load your prior altered one ... this is what I usually do as during switch overs your concentration is never the best .. smile)
Reboot your router
Reboot your firewall
Test connectivity out
Test connectivity in (telnet etc)
Sit and wait for replication to occur from the DNS steps so your services will start working.

IF .. your firewall will handle BOTH your old circuit and your new circuit, you could configure it to accept mail etc on both old and new IP while replication takes place.

For your DNS

Move your name servers
Create your NEW records
Sit and wait.
Jon BrelieSystem ArchitectCommented:
Can you add both lines?  IE: old ISP and new ISP concurrently?  If so, you can do this with zero downtime.

Otherwise, you're looking at whatever the TTLs are on your current host.

If you cannot, then your best bet is to move DNS to *before* you change the lines.

1.  Change Auth NS to, and setup identical records.  No downtime because remote hosts will either go to your old ISP or  It  doesn't matter which they hit because the records are identical.

2. CALL and ask them to manually set the TTL on your hosted records there as low as possible.  ( tools do not allow you to specify TTL)

3. On new ISP day, have your new records ready to go and update them at as soon as your new line is coming up.  (here you are subject to *potential* downtime for clients, but shouldn't be any longer than the TTL at
tenoverAuthor Commented:
"1.  Change Auth NS to, and setup identical records.  No downtime because remote hosts will either go to your old ISP or  It  doesn't matter which they hit because the records are identical."

I like this route, however it looks like as soon as I click on the choice to "use domain name servers", it will take over and remove my current name servers, which currently hold all the records.  There doesn't seem to be a way to go in and copy all my records over, and then on Friday, "flip the switch" to move from OLDISP name servers to nameservers.....
Jon BrelieSystem ArchitectCommented:
Correct. will become THE nameservers.  However remote clients that have cached the old name servers will still get valid records from the old servers until they are refreshed to use the "correct" servers.

Essentially, Yeah they're looking in the wrong place, but it doesn't matter.  Whether they look at the old servers, or the new, they'll still find the droids they're looking for.

You only have a handful of records.  If you create them immediately after taking DNS Auth over at, you'll have TWO fully functioning DNS authorities that will answer requests until things propagate and everyone is using
tenoverAuthor Commented:
"If you create them immediately after taking DNS Auth over at, you'll have TWO fully functioning DNS authorities that will answer requests until things propagate and everyone is using"

That is, if I update BOTH the OLD(OLDISP) and NEW( around the same time, right?  Once I switch ISPs(remember, all the public IPs are changing) then the OLD IPs won't work at all.......??
Jon BrelieSystem ArchitectCommented:
Nope, nope, nope.

You want to change DNS providers well before you do any actual network changes.  That way everything is settled and all remote clients are using

Like a week before.

That way you only have to change them in ONE place when you make your actual IP changes.  You're still subject to a minor interruption in service - about equivalent to whatever your new TTLs at are.

But at least you won't have any outages during the DNS shift.

Trying to do them at the same time doubles your potential failure points.
tenoverAuthor Commented:
Ok, thanks.  So what you are recommending, if the cutover is this Friday.....

On Wednesday, change my name server(s) from OLDISP to and copy all the current records over to, as they exist today(won't these changes still take a long time to propagate?? Outage would occur HERE instead of at cutover).

On Friday, right before the actual cutover, login to and make all the DNS/IP modifications.

Make NAT/Address changes on Firewall(SonicWall NSA 3500)
Reboot Router.
Reboot Firewall.

Jon BrelieSystem ArchitectCommented:
Pretty much, yes.

But not Wednesday.  Do it tomorrow.  DNS propagation doesn't take as long as it used to.

Everything else is fine, except for one thing:
Some remote clients will cache auth DNS servers for a domain and won't bother to check for updates as long as they are still getting records from the servers they are checking.

So:  Once you make the cut on the line and update records at, call your old ISP and ask them to delete the zonefile for your domain from their servers.  When stubborn clients can't get the records they are looking for, *then* they'll finally do a public authDNS lookup and find where to go. (

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tenoverAuthor Commented:
Thanks.  I have a direct line to our current(small time) ISP, and they can delete within minutes. So to sum it up.......

- Login to sometime in the next 24 hours and make them my new nameserver(s)
- Recreate all current DNS records from OLDISP to immediatley(downtime will occur here)
- Upon cutover(This Friday, late afternoon), log back in to and modify records to reflect NEWISP public IP addresses(downtime will occur here).
- Make any WAN interface/NAT changes on firewall
- Reboot Firewall
- Reboot router.

Jon BrelieSystem ArchitectCommented:
Plus call your existing ISP to get the (now) incorrect zonefile removed.

You got it.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.