Home / server / Questions / 293448
In Process
Manca Weeks
Asked: 2011-07-24 16:36:12 +0800 CST

How long will an MX record and A record change take when DNS server is not being changed?

  • 772

I am trying to estimate whether it is realistic for me to change the IP of a mail server overnight or will this mess with people retrieving their email the day after. Basically, the facility where the mail server is will be changing its IP pool and this forces me to have to change the A and MX record for the mail server. Since I am not changing the DNS server itself (not moving the records to a different authoritative server), will the change be near instantaneous or will it still take up to 48 hours because of caching on different non authoritative DNS servers that may have queried recently?

Thanks for any insight,

M

domain-name-system

4 Answers

  1. Every DNS resource record is cached; whether the DNS server itself is moving or not is immaterial. As Yahia said, how long the record is cached is determined by the TTL of the record. Before performing a DNS change, it is common practice to lower the TTL from it's regular value (a day or more, typically) down to something really small, like 5 minutes.

    Complicating this procedure is the fact that some badly-behaved dns caching resolvers ignore the specified TTL and substitute their own values. (The people running these systems need to die in a fire, and if I ever get elected Grand overlord of The Internet, they will). As such, if it's an important system or one used by people outside your direct control, you would be well advised to setup DNAT rules on the system being migrated away from to redirect traffic that does get sent to the previous IP address to the new one.

    • 34

  2. Do you already know the new IP address? If so, you're in luck! Setup a new A record, subdomain for your domain, pointing to the new IP, then add that as an extra MX record; set the priority higher on the new one than the old MX record. Do this a couple of days before the new IP is supposed to be activated. After the new IP address is active, remove the old MX record, leaving the new MX record. Remember to update your SOA serial each time you make edits.

    Here's an article outlining failover/backup MX records: http://www.zytrax.com/books/dns/ch9/mail.html

    • 7

  3. The most important setting in you senario is TTL of the respective DNS records.

    The lower the TTL is set the better - you usually won't get to "instantaneous" because of all the DNS servers out there which have diverse caching behaviours but the lower TTL is set the better your results will be...

    • 5

  4. Changes to DNS should be relatively instantaneous on your authoritative servers. However, due to DNS cashing it will take a while for the changes to get out to clients. This will be more of a problem for frequent clients than occasional clients. You can work around this by pre-populating your data.

    The various answers already posted cover everything you need to worry about.

    • Set the TTL on to a low value. Say 1H a few days before the change. Try to do this at least the current TTL before the change, 2 times TTL would be better.
    • Add two new A records for the mail server using the old and new addresses. Create an MX record for each of these giving highest priority to the old server address. Remove the MX for the old address as soon as you cut over. Set the priority on both these records lower than the existing record. (Sending servers shouldn't check the name your banner uses.
    • Add a new A record for the mail server with its current name. And get the PTR record setup for the new address The A record will return both addresses. This will allow rDNS validation to work for either address. (Many receiving servers care about this and may refuse messages or classify them as spam if rDNS fails.)

    You are now ready for the cut-over to the new address. After the cutover you can cleanup.

    • Remove the MX records for the new names and the A record for the old address.
    • Wait a few hours and remove the A records for the new names.

    This should be completely transparent to your users. Any problems you encounter should be restricted to servers which are non-compliant with standards.

    You can use the double A record technique for other services, but there will be delays when clients try the address which isn't responding and wait for it to timeout.

    • 0