Great advice. The only thing I'd add is that the RFC says the minimum TTL
that a caching server has to honor is 2 days. That means it could take up
to 2 days for it to be reflected globally.
Depending on the line of business (are they a 9-5 shop, or a 24/7 web
presence?), I have two ways of doing it.
9-5, M-F business:
I usually recommend to customers to do this on a Friday at 6pm. That way by
Sunday 6pm things should be cleared out of caches on a global basis.
24/7 shop:
Bind two IPs to the device, the new and the old (or two private addresses
and have your firewall/NAT take those two private addresses to the old and
new public address). With this approach, you can do it any time you like as
both IPs are valid and work (make sure you application(s) know to expect
both, of course). In two days, check all of your slave (secondary) DNS
servers to make sure they're correct, and randomly sample a few ISPs (using
nslookup -q=a foo.bar.com ns1.isp.com). If it looks good, ditch the
original IP address and continue using the new one.
They key here is to have control of your DNS and/or have folks you know will
change things properly and in a timely manner (and then verify those changes
yourself). With the 24/7 cutover with two IPs, it's not nearly as big a
deal. Of course the 24/7 approach assumes that you can keep both ISPs
connected at the same time. If not, you're stuck with a weekend approach
(or pick the best 48 hours to have potential loss of connectivity).
--
Jason Roysdon, CCNP+Security/CCDP, MCSE, CNA, Network+, A+
List email: [EMAIL PROTECTED]
Homepage: http://jason.artoo.net/
""ElephantChild"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Fri, 25 May 2001, Scott Meyer wrote:
>
> > I have a question about changing ISP's when a domain name(s) is
registered
> > to an IP address(s) owned by the ISP.
> >
> > Obviously, we need to get the DNS registration changed to an address
owned
> > by the new ISP. I have had some transitions that have not been real
smooth,
> > and would like the current best practice for doing this.
> >
> > Any input is apprectiated.
>
> ObWhereDidItGo: Does anyone know where the "Ask Dr. DNS" web site went?
> I wanted to point the poster to it, but couldn't find it. Oh well...
>
> Just making sure I understand you right:
>
> - You are the proud owner of domain bar.com.
> - Some machine foo.bar.com is a public resource on your network, and it
> is about to get a new IP address (or perhaps a group of machines is).
> - You want to avoid becoming the proud owner of a giant headache.
>
> In the procedure below, I'm going to assume that a 1-2 hour window from
> the time you switch over the server and the time the last clients
> elsewhere on the Internet see the new address is tolerable. Also, some
> of the parameters below are arbitrary. Adjust as you see fit.
>
> The key is to have direct control of the primary, or master, name server
> for your domain. If you don't have that control, get it handed to you
> ASAP. Well, perhaps not to you personally, but it should be controlled
> by your organization, not by your ISP. Otherwise, you will most likely
> have problems.
>
> With that done, the rest is comparatively easy. Lower the minimum and
> refresh times for your domain (in the SOA for domain bar.com, in my
> example) and the TTL for the resources you're switching (the A for
> foo.bar.com), in the weeks and days before the switch. Exactly when and
> by how much, depends on the initial value. Assuming they were set to 1
> week (a common value), you could set them to 24 hours 8 days before the
> switch, then to 1 hour 36 hours before the switch.
>
> When the time comes for the switch, change the address(es) *and the
> serial # in the SOA*, and make your master server reload the zone. Check
> that it loaded correctly, then have your slave servers get the zone from
> the master. (Note: some of your slave servers may not be under your
> control, and their admins may be reluctant to empty their dearly bought
> name cache just for you. Don't lose too much sleep if that happens:
> Thanks to the previous step, they will reload your zone anyway in at
> most 1 hour, and most if not all clients will see the changes in at most
> 2 hours.) Test that clients go to the new address for the server.
>
> Let it rest some time, say 24 hours, until you're sure the changes have
> had time to percolate everywhere but to the more weirdly (and probably
> incorrectly) configured name servers, then change the refresh and
> minimum values on the SOA and the TTL on the A resource back to their
> former values. Don't forget to change the serial # again. This time,
> don't bother reloading your slave servers or bugging sysadmins. They'll
> pick up on the changes soon enough without needing human intervention.
>
> --
> "Someone approached me and asked me to teach a javascript course. I was
> about to decline, saying that my complete ignorance of the subject made
> me unsuitable, then I thought again, that maybe it doesn't, as driving
> people away from it is a desirable outcome." --Me
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=5953&t=5898
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
