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
apt-cache show 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
Does anyone use that already? Port 25 forwarding? Does ist forward to
arbitrary adresses unlike NAT-forward which does only forward to NAT
Currently we don't move servers, but time will come and I want to be
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
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.
Tel: +49 69 85700331