2017-09-23 23:54:48 +02:00
|
|
|
#!/bin/cat
|
2019-07-03 01:17:46 +02:00
|
|
|
$Id: FAQ.TTL.txt,v 1.2 2018/05/24 11:34:30 gilles Exp gilles $
|
|
|
|
|
|
|
|
This document is also available online at
|
|
|
|
https://imapsync.lamiral.info/FAQ.d/
|
|
|
|
https://imapsync.lamiral.info/FAQ.d/FAQ.TTL.txt
|
2017-09-23 23:54:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
=====================================================================
|
|
|
|
Imapsync tips about TTL when changing name resolution of hosts
|
|
|
|
=====================================================================
|
|
|
|
|
|
|
|
Why decrease the TTL (Time To Live) delay in DNS configuration, down
|
|
|
|
to 5 minutes?
|
|
|
|
|
|
|
|
A small TTL is not mandatory, it's safer and more easy to work with when
|
|
|
|
migrating.
|
|
|
|
|
|
|
|
It's about how long it takes to be sure the users are using the new
|
|
|
|
imap host, and how long it takes to be sure all new incoming messages
|
|
|
|
are going right now at the right place. Will you shut down the old
|
|
|
|
server just after the resolution change? I guess you won't and you'll
|
|
|
|
be right.
|
|
|
|
|
|
|
|
The TTL is just a value, very well supported by machines, with a
|
|
|
|
little name resolution supplementary work for them when it is set to a
|
|
|
|
small value like 5 minutes, but it's a tremendous comfort for migrator
|
|
|
|
people like us.
|
|
|
|
|
|
|
|
Be sure to wait 24h after this TTL change before changing any
|
|
|
|
resolution since the TTL change has to be propagated as well. After
|
|
|
|
the migration done, no problem to set back the TTL to 24h or more. If
|
|
|
|
you can't decrease TTL under 4h or even 24h, it's ok anyway, imapsync
|
|
|
|
can sync the new messages dropped in the old server.
|
|
|
|
|
2019-07-03 01:17:46 +02:00
|
|
|
=======================================================================
|
|
|
|
=======================================================================
|