Physically Moving A Mail Server Vs. Cached DNS

Home » CentOS » Physically Moving A Mail Server Vs. Cached DNS
CentOS 6 Comments

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

6 thoughts on - Physically Moving A Mail Server Vs. Cached DNS

  • 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 :

    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.

  • Yes, or use dig or something else that shows the TTL

    The TTL is part of the DNS record so no, they shouldn’t override it, in the same way as they shouldn’t override the A record or MX record. That doesn’t mean that some providers don’t do it “for operational reasons”, but it’s a stupid thing to do and will basically, literally, break the internet.

    P.

  • ———— Original Message ————

    You should check to see if your old SOA is still showing themselves as authoritative for your domain. If they are, then anyone who uses their nameservers will still get the old record(s) for your domain.

    If they are still showing themselves as authoritative (which I think is the case) you will want to contact them to have them drop your domain from their server(s), or at least get your host records updated to point to your new servers.

  • Yes, that does seem to be the case.

    Nicolas, if you make the query directly from the nfrance.com servers you can see what we mean:

    $ host -a microlinux.fr ns.nfrance.com
    Trying “microlinux.fr”
    Using domain server:
    Name: ns.nfrance.com
    Address: 80.247.224.77#53
    Aliases: 

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2088 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 7 ;; QUESTION SECTION: ;microlinux.fr. IN ANY ;; ANSWER SECTION: microlinux.fr. 9600 IN SOA romeo.hebergement-discount.com. dns.nfrance.com. 2012081401 43200 1800 864000 9600 microlinux.fr. 9600 IN NS ns2.slconseil.com. microlinux.fr. 9600 IN NS ns1.slconseil.com. microlinux.fr. 9600 IN NS ns3.slconseil.com. microlinux.fr. 9600 IN MX 10 mx1.nfrance.com. microlinux.fr. 9600 IN A 80.247.228.60 ;; ADDITIONAL SECTION: ns1.slconseil.com. 432000 IN A 80.247.224.77 ns1.slconseil.com. 432000 IN AAAA 2a00:1a60:22e0:4d00::1 ns2.slconseil.com. 432000 IN A 80.247.228.129 ns2.slconseil.com. 432000 IN AAAA 2a00:1a60:21e4:8100::1 ns3.slconseil.com. 432000 IN A 81.25.194.8 mx1.nfrance.com. 60 IN A 80.247.229.29 mx1.nfrance.com. 60 IN A 80.247.228.29 So nfrance.com still claim SOA on your domain. At least they have a relatively short TTL on it of 9600s so things will correct themselves quite quickly once they drop the domain. P.

  • …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.

LEAVE A COMMENT