[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to relocate servers transparently


The "DNS Trick" should do it.

Instead of "internal" E-Mail Forwarding of ricochet E-Mails I think about some kind of port-based forwarding. By random I ran accross "rinetd" package.

apt-cache show rinetd
Package: rinetd

Description: Internet TCP redirection server
 rinetd redirects TCP connections from one IP address and port to another,
 with basic IP-based access control.
 rinetd is a single-process server which handles any number of connections
 to the address/port pairs specified in the file /etc/rinetd.conf. Since
 rinetd runs as a single process using nonblocking I/O, it is able to
 redirect a large number of connections without a severe impact on the
 machine. This makes it practical to run services on machines inside an IP
 masquerading firewall.

Does anyone use that already? Port 25 forwarding? Does ist forward to arbitrary adresses unlike NAT-forward which does only forward to NAT adresses?

Currently we don't move servers, but time will come and I want to be prepared. :-)


Brad wrote:
Rhesa Rozendaal wrote:
 > In the past I witnessed such a move, and there were a lot of problems
 > with the DNS. As it turned out, many DNS servers out there kept caching
 > the old ip addresses for over 3 days, causing a lot of connection issues

This is most often due to the old authoritive servers continuing to serve the old zone details. When an A record is refreshed, the TTL for SOA/NS rr's also refreshes, therefore the NS information 'seems' to never be out of date. Some DNS caches will continue querying the old servers due to the fact that those NS records have not expired.

 > for many users. Beforehand we did lower the ttl on all the domains prior
 > to the move, but many dns servers seemed to ignore that. On top of that,
 > we moved both our dns servers at the same time, which was a big mistake
 > too.

When moving a site to new IP's/DNS servers I performed the following:

Create all accounts on the new box, and copy all the files over. Setup the DNS servers to issue the new zone details. At the same time, configure the OLD servers to serve the new zone data. When the old servers are queried, they will serve the new zone data, so when an A record is refreshed, the SOA/NS records will be that of the new servers.

You can then change the delegation for all domains to the new DNS servers.

I guess the trick is to keep both DNS servers going at the same time for a few days, but ensure that they are all serving the NEW zone details for all domains. This would be the 'correct' way to change delegation and will also avoid 'server lock' (as ISC refer to it) as mentioned above with the NS records refreshing.

 > So, what I'd like to hear from you is practical advice on how to avoid
 > connection problems after the move is complete.
 > Will it be enough to keep 1 dns server behind? I'm afraid it won't be,
 > given the dns caching problem mentioned above. Is there a way to have
 > that 1 dns server act as a proxy or port forwarder in some way? Can that
 > be done between two different class A networks?

As above, as long as both new and old servers are serving the same (new) zone details, there shouldnt be a problem.


Andreas John
net-lab GmbH
Luisenstrasse 30b
63067 Offenbach
Tel: +49 69 85700331


Reply to: