• 0

A way to keep emailing active durning host switching


Go to solution Solved by primexx,

Question

Kalint

We're moving away from our current host to a better one but I have just one issue.  We get a lot of emails and I know that the whole process of moving from host to host can take days to do.  Is there a way we can do some sort of dns forward to keep our emailing active until the process is done?

Link to post
Share on other sites

6 answers to this question

Recommended Posts

  • 0
primexx

The "up to a few days" estimate is a high end limit. It usually takes a few minutes to a few hours for changes to propagate. If you're able to change the TTL on your DNS records start shortening it before your planned migration so that records expire every few minutes, that way other DNS servers are constantly checking for your new records during the migration. This helps to reduce the down time generally. Other thing you can do is to set up your new host before updating the DNS records, so that the moment it starts receiving traffic it's ready to actually do something with them. That way it doesn't really matter when the DNS records update, because before the update they'll be sent to the old server, which knows how to handle your emails, and after the update they'll be sent to the new server, which you've also already set up to know how to handle your emails. The records don't just turn blank the moment you change them on your end, they stay the old record until they see a change and updates to your new records.

Link to post
Share on other sites
  • 0
sc302

What he said is true. What I would do is when the new server is ready, make the mx change, turn off the old one or the smtp services then wait for the internet to catch up. It is best to do this over the weekend to make sure everything settles properly.

Link to post
Share on other sites
  • 0
Kalint

Are you guys serious?  Last time we did this with gearhost it took almost a week for the domain to get ready.

Link to post
Share on other sites
  • 0
sc302

I have done many mail server installs. Yes.

Change the ttl now to as low as you can go, 15....

Once set then it should take a max of 15 min to begin propagation to the internet dns servers.

Link to post
Share on other sites
  • 0
Kalint

Well alrighty then!  +1 to you guys

Link to post
Share on other sites
  • 0
+BudMan

" The records don't just turn blank the moment you change them on your end, they stay the old record until they see a change and updates to your new records."

Not a fan of this wording..

Lets go into a bit more detail here..

So lets use neowin.net mx record for an example.

budman@ubuntu:~$ dig @ns1.neowin.net neowin.net mx

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> @ns1.neowin.net neowin.net mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39438
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 3, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;neowin.net.                    IN      MX

;; ANSWER SECTION:
neowin.net.             21600   IN      MX      5 alt1.aspmx.l.google.com.
neowin.net.             21600   IN      MX      10 aspmx3.googlemail.com.
neowin.net.             21600   IN      MX      10 aspmx2.googlemail.com.
neowin.net.             21600   IN      MX      10 aspmx5.googlemail.com.
neowin.net.             21600   IN      MX      5 alt2.aspmx.l.google.com.
neowin.net.             21600   IN      MX      1 aspmx.l.google.com.
I queried an authoritative ns for neowin.net so we could see the actual TTL and not the countdown value you might see at another dns, example of that

budman@ubuntu:~$ dig neowin.net mx

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1 <<>> neowin.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65383
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;neowin.net.                    IN      MX

;; ANSWER SECTION:
neowin.net.             21326   IN      MX      5 alt1.aspmx.l.google.com.
neowin.net.             21326   IN      MX      5 alt2.aspmx.l.google.com.
neowin.net.             21326   IN      MX      10 aspmx2.googlemail.com.
neowin.net.             21326   IN      MX      10 aspmx3.googlemail.com.
neowin.net.             21326   IN      MX      10 aspmx4.googlemail.com.
neowin.net.             21326   IN      MX      10 aspmx5.googlemail.com.
neowin.net.             21326   IN      MX      1 aspmx.l.google.com.
So the TTL neowin has setup on their mx records is 21600 seconds, or 6 hours.

So once some name server gets asked to lookup mx for neowin.net depending on where he gets his info, from an upstream cache it might be something less than 21600, depending on the upstream ns he got his info from, and if he had a cached entry. If the query ends up going all the way to neowin's ns it would get the full ttl of 6 hours. He would then never check for this again no matter how many times he gets asked, until his local counter on the ttl expired. Once it has expired, the next query he gets for neowin.net mx he would then go ask the ns he points to, or roots, etc.

So in this example if neowin.net would want to change where their mx record points too. Sometime longer than 6 hours they should change their TTL to something very small - lets say 5 minutes. After 6 hours has passed we are sure that every cached entry on the entire planet could be no more than 5 minutes.. But you are not sure of that until that 6 hours has expired - since someone might of just cached it 1 second before you changed it to 5 minutes.

So after the 6 hours has expired, and we are now using a ttl of 5 minutes. You could change the MX record, and be assured that everyone on the planet will be pointing to your new MX record within 5 minutes. You could set the TTL record to whatever you want, be it hours, days, weeks, etc. And this would be how long they cache those records once they query for them.

The only thing you would have to worry about is anyone using a name server that is not using valid TTLs -- some times you find isps or whatever breaking their nameservers so they cache all records for a specific amount of time, no matter what the actual TTL of the record was.. That is on them, and they are breaking the rfcs if they do that, etc.

  • Like 1
Link to post
Share on other sites
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.