We need a technical clarification, as our original assertion is being questioned. Please read the scenario below and advise..

We are in process of transferring a customers domain name away from our servers to the servers of a large ISP. We'll use custdomain.com ourdns.com and largeisp.com for this example to protect the innocent.

Custdomain.com is currently listed in network solutions with name servers ourdns1.com and ourdns2.com. We use an alabanza cp therefore we do not access the SOA records ourselves.
We intend to update the network solutions database with the DNS records of dnslargeisp1.com dnslargeisp2.com and dnslargeisp3.com so their technical geeks can control the entire web hosting solution.

Our concern is for extended customer downtime.

We made the following recommendation to the largeisp.com technical team, HOWEVER the state our recommendation is impossible to accomplish without us first transferring the custdomain.com name in the ns database.

We requested they modify the SOA records on their DNS server to reflect the transfer of domain, and once completed we will initiate the transfer with network solutions. Our thought is that the old DNS information will still resolve until it times out (48-72 hours, then the new authoritative name servers dnslargeisp.com
will be queried and resolve the custdomain.com URL properly.

Have we mad an incorrect assertion that largeisp.com can change their public name servers SOA records prior to the network solutions isp update? Our thought is the only issue is lame delegation which will not impact the custdomain.com URL since dnslargeisp.com will not be queried until the network solutions database is updated. In other words do their name servers have to pull the information from network solutions? Or is network solutions only role to point to dnslargeisp.com for information?

Please help out here, as the technical intricacies are left to others in my organization, and the largeisp.com's technical team has me second guessing our "quasi-technical" resource.

This is easy. If I read you correctly you want to do the following.

Move domain.com to another host.
Change namerserver records to other namerservers.

ok.. this is what you do.

Find out what the TTL is on the domain currently. This is how long you have to wait before you start moving the domain.

Change the current TTL to 3600 or 1 Hour. Restart the name server.

1 day before the TTL expires, Add the zone to the current name servers and upload your web site to the new server.

The night before the TTL on the old nameserver expires put the reques to the registrar to change the nameservers. This will take 24 to 48 hours to propogate.

Leave the old site up with a link or redirect it to the new IP, just incase some ISP's to not restart their caching nameservers.

With any luck there will be no more than 1 hour of downtime or less.

Easier solution, if largeisp.com uses static IPs:

Set up the account at largeisp.com for your client. Initiate the necessary DNS changes at NetSol. Go to the master server in your Alabanza cluster, and from a command line run
/etc/named/setupdns domain.com 1.2.3.4

where 1.2.3.4 is the IP assigned by largeisp.com for that account.

When NetSol completes the change, remove the entry for the domain:
/etc/named/setupdns domain.com del

Remove the record from the machine if necessary.

This is what has worked for us when transferring sites off our Alabanza servers to our NAC servers. Zero downtime.

Thank you both for your replies.

Annette - I have no control over largeisp.com. Should I insist they complete any steps on their side prior to my net sol move?

Also should I contact Alabanza directly for the change? I am only a reseller now.

Originally posted by MattG
I have no control over largeisp.com. Should I insist they complete any steps on their side prior to my net sol move?

Yes, but I see their reasoning. Any access attempts of that site that comes from a user within the largeisp.com's network or from any email send to this domain from a mailserver using largeisp.com's mail exchange with bounce and depending how large the number of access attempts is, this can cause strain on their network.

But the timing of all of these changes can be scheduled so that everyone will be happy.

Annette is correct - if you change the zone records on the current nameservers to relect the new location, and the website and email have been installed on the new server and the old site is redirected to the new location for any cached dns access attempts, there shouldn't be hardly any downtime.

You usually can't insist that large ISPs do much of anything. :)

However, ideally, the new site on largeisp.com would be set up before anything else, just so the infrastructure is there when things start rolling. If they offer static IPs (some do, some don't), then the method above will work, and it won't really matter how long it takes NetSol to pull their thumb out of their butt and get things done. If they don't use static IPs, you're likely to be stuck with the old site until the modifications propagate for it. No big deal, but if any of the settings at largeisp.com are different, you'll need to warn the client that if they start getting errors that they'll need to change the settings they use.

If you're a reseller, that throws another level into the mix. For the method above, you'll need to ask your upstream to make the change for you once the new site is set at largeisp.com. It's a very simple process, and most hosts should not have a problem with running a one line command from a shell session on their primary nameserver box. Of course, if they don't, then you're back to old standby of leaving the account active until change propagation is complete.