Forum OpenACS Q&A: Re: Modifying Server IP addresses (or Virtual Hosting in Reverse)

You should set the TTL in the DNS entries to a very low setting. This will cause properly configured upstream DNS to cache the old address for a very short time.

Them when you switch the DNS the clients will contact the DNS server and get the new address because the old one will not be cached.

If you already switched I do not have any advice, sorry.

I appreciate the response. This is an excellent suggestion and I wish I had done that the first time. Still I wonder what is really happening in the network communication?

Here is what I assume, maybe someone can shed some light?!

Pound is listening on 1.1.1.1:443. It connects to client and creates the secure tunnel. All requests are tunneled through a connection like this (not all through the one connection). The pound process connects to a backend address/port. This backend port should be "sniffable" to look like any other get request. ie "get /page". The oacs process is seeing that the request for www.abc.com is coming from 1.1.1.1 but the server thinks it's ip address is 2.2.2.2 so it never responds with anything. Or is it not suppose to respond?

Is there a way for pound to change to packet contents such that it can fool the AOLserver (and client)?

There are a number of approaches. One is to set up your favorite redirector (mine would be *bsd/pf, second *bsd/ipfilter) listening to the old address and forwarding to the new address.

Yes, there are a number of way to skin this cat, and they can make a net admin who comes upon an in-process migration where folks hadn't remembered what Dave said about the DNS feel like a hero when it gets pulled off. However, the sad result is that said net admin gets the wrong reinforcement and now is also lliable to ignore what Dave said about the DNS in future migrations and is setting themselves up for great trouble. For there be dragons lurking in many of these port redirection/tunneling/aliasing tricks.

Now, there exist some resolvers out there, not so many as before, but still a few, which do not honor the TTL. And there used to be some browsers which cached their names instead of relying on their resolvers. In both of those cases, Dave's sage advice would *seem* to be incorrect. However, it would quickly identify said resolvers and browsers, and allow for their expeditious removal and replacement. Thus proving for all time the ultimate value of what Dave said abour the DNS.