CentOS - Jul 2017 - Physically moving a mail server vs. cached DNS

Hi,

I just moved my main mail account and web content from a low-cost
(low-quality) provider to my own root server running CentOS 7. I
transferred the domain name from DNS management to my registrar,
configured BIND, Apache, Postfix, Dovecot, NTP, SELinux, etc. Now things
are running rather nicely. One thing is puzzling me though.

The updated mail server DNS seems to have spread around so far.

$ host -t mx microlinux.fr
microlinux.fr mail is handled by 10 mail.microlinux.fr.

Unfortunately, some hosts seem to still keep the old DNS information,
which was:

$ host -t mx microlinux.fr
microlinux.fr mail is handled by 10 mx1.nfrance.com.

In your experience, what's the "longest" a DNS cache is configured
to
keep outdated information? A day? A week? A month? Longer?

Cheers,

Niki

> 
> In your experience, what's the "longest" a DNS cache is
configured to
> keep outdated information? A day? A week? A month? Longer?
> 
That is controlled by the TTL (time to live) entry. A DNS server must
refresh it's cache within the TTL for the entry. Using the '-a'
option
to host will give you more information:


    $ host -a microlinux.fr
    Trying "microlinux.fr"
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2261
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

    ;; QUESTION SECTION:
    ;microlinux.fr.    	    	    	    IN    	    ANY

    ;; ANSWER SECTION:
    microlinux.fr.    	    	    86400    	    IN    	    SOA    	   
ns.microlinux.fr. hostmaster.microlinux.fr. 2017070101 10800 600 1814400 10800
    microlinux.fr.    	    	    86400    	    IN    	    A    	   
195.154.171.195
    microlinux.fr.    	    	    86400    	    IN    	    MX    	    10
mail.microlinux.fr.
    microlinux.fr.    	    	    86400    	    IN    	    NS    	   
ns.microlinux.fr.
    microlinux.fr.    	    	    86400    	    IN    	    NS    	   
nssec.online.net.

    ;; ADDITIONAL SECTION:
    mail.microlinux.fr.    	    86400    	    IN    	    A    	   
195.154.171.195
    ns.microlinux.fr.    	    86400    	    IN    	    A    	    195.154.171.195


The '86400' is the TTL - it's in seconds so that's 24 hours. So
it all
depends on what the TTL was set to for your old DNS provider.

TTL is a balance between accuracy and network traffic - most DNS
entries don't change for months, so 24 hours is perfectly acceptable.
If accuracy is an issue while a DNS entry changes, then admins often
reduce the TTL during the transition period.

If a particular host is still serving an old DNS entry from its cache
after a TTL has expired, then it's broken. There's not a lot you can do
other than shout at the hostmaster or wait until its personal view of
the world expires.

P.

Le 01/07/2017 ? 11:00, Pete Biggs a ?crit :
> That is controlled by the TTL (time to live) entry. A DNS server must
> refresh it's cache within the TTL for the entry. Using the '-a'
option
> to host will give you more information:
So I would have to use the -a option with the old DNS server, to know
their TTL. I'm also wondering if some DNS server don't override the TTL
and keep the information longer. I remember such a case where the DNS
server of the french provider Orange kept a stale DNS information forever.

On Jul 1, 2017, at 3:00 AM, Pete Biggs <pete at biggs.org.uk>
wrote:
> 
>> In your experience, what's the "longest" a DNS cache is
configured to
>> keep outdated information? A day? A week? A month? Longer?
>> 
> That is controlled by the TTL (time to live) entry.
?which is often under your control as the domain owner.

A common practice when moving hosts between providers like this is to
temporarily shorten TTL from its normal working value to something much shorter,
wait out the original TTL, do the move, wait out the new shorter TTL, and put
the TTL back up to its previous value.

For example, if the normal TTL for the domain is 24 hours, then 24+ hours before
the move, you could set TTL to 1 hour, then move the host 24+ hours later, so
that any client that queries the DNS for that domain will get the 1-hour TTL. 
Then 1 or more hours after you?re sure everything is fine, put TTL back to 24
hours.