If I change our company's DNS to a different host, will it keep our email from working?
I am unsure of how MX handling works, but right now we are routing our email through postini (anti-spam service) and then its being sent to our domain. I would think that changing the DNS would only mess with the web portion of it, but it would be the end of me if email went down for even half a second.
Pleas help!
Software/Hardware used:
ASKED:
January 4, 2008 5:28 PM
UPDATED:
February 22, 2008 7:16 AM
Thanks for the helpful advice!
The proposed DNS change should take place over a weekend to allow for propagation of the DNS records throughout the Internet. Your users should be aware of the change in case there are any outages as a result. Then you will probably want to kick the change off on Friday evening and by Monday, everything should be working — provided the changes were made correctly.
No problem, I’m glad to help.
Here’s a trick to not have to work the weekend (if you can get away with it)… I’ve done it this way many times with no ill effects relating to “propigation”. IMHO, the propagation myth is perpetuated by Network solutions insistance of only updating the DNS zone files 2 times a day– however, keep in mind this is only for root and TLD name servers. Essentially, the 36 hour quote they tell you is their way of padding the timeline. Like telling your boss you can get it done in a week, when you know it will only take a day or two because you KNOW he’s going to pull you off atleast 3 times in the week to work on the VP’s installation of Microsoft Dinosaurs.
Here’s the tip…. 3 days before needing to make the change drop your TTL on the records needing changed (or the DNS domain) to 1 hour. That should allow time for the old setting to fall out across the internet.
Then you can change the record and only have to wait a couple of hours before you know your tests are good.
Reference rfc 1035 for more information on TTL, but here is an excerpt:
a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data.