14

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

Improve this question
0

4 Answers 4

Reset to default
34

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.

Improve this answer
6
  • 16
    +1 "The people running these systems need to die in a fire, and if I ever get elected Grand overlord of The Internet, they will" - You've got my vote.
    – Chris S
    Jul 24, 2011 at 2:35
  • That's the issue - the email server will be the same. The building is switching to a new IP address pool and therefore only one of the IPs can be active at a time... So I can't set up anything on the old one..
    – Manca Weeks
    Jul 24, 2011 at 14:00
  • @womble: Unfortunately spammers have been using fast flux DNS to move their servers and avoid detection. As long the the DNS admins are not setting unreasonably long times for their minimum TTL I support their actions to defeat these illegal operations. However, it does make transitions more difficult.
    – BillThor
    Jul 24, 2011 at 18:04
  • Idiots have been overriding TTLs for a lot longer than spammers have been using fast-flux, and overriding TTLs obviously isn't working because spammers are still doing it. TTLs are not the place to be fighting spam. They're still going in the fire.
    – womble ♦
    Jul 24, 2011 at 21:15
  • Exactly, the side-effect is that DNS changes can take, literally, up to 24h to propagate fully. That hurts when you have a localized network connectivity problem and want to apply a quick fix to re-route traffic to backup link/facility.
    – Hubert Kario
    Aug 21, 2011 at 14:36
7

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

Improve this answer
2
  • won't this method potentially cause the new IP to become active before it as actually activated? resulting in the same issue I am trying to prevent - people not being able to receive or retrieve mail? Also - anything I should know about the SOA serial? I have never done much DNS administration, only moving from one hosting provider to another, where all the actual DNS records were set for me, I just had to input the delegation at the registrar.
    – Manca Weeks
    Jul 24, 2011 at 14:03
  • 1
    @manca No, these are additional records. The point of having multiple MX records is to have more than one valid path in case something goes down. In effect, you are just failing over to the existing server until it gets reconfigured.
    – Tall Jeff
    Jul 24, 2011 at 17:22
5

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

Improve this answer
1
  • Well, I didn't really mean instantaneous. The goal would be about 12-14 hours... If I can do that I will be just fine. I guess one way to make the DNS not matter at all would be to input the actual WAN IP on all the mail client settings - this way it wouldn't matter. There are only about 40 of them...
    – Manca Weeks
    Jul 24, 2011 at 14:46
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .