Changing Internet service and avoid interrupting email

bsdme2

Junior Member
Jul 16, 2015
2
0
16
Hi Folks,
Need some idea and suggestion.
Right now, my company have DSL Extreme for internet service. They host our email also. We purchase
8 static ip from DSL Extreme more than a decade ago. We register our domain name with Network Solution. Since DSL Extreme no longer renew our DSL service, we want to move to ATT for DSL service, but we don't want our email service to be interrupt since it is our main communication with our customers. Anyone can suggest me how we can move to ATT for DSL service and still be able to use our current email?
Thanks in advance,
bsdme2
 

JackMDS

Elite Member
Super Moderator
Oct 25, 1999
29,471
387
126
I do not know what your"Deal" with DSL Extreme is? If the Domain Name is Registered with Network Solution and it is yours, you can contact Network Solution and move it to resolve on another server/host of your choice and copy the content of the current server to it..


:cool:
 

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
If you host your own mail server in your company, downtime probably unavoidable since your mail server's IP definitely will change if you switch from DSL extreme to AT&T. The IP change will need time to propagate to DNS servers around the world.
 
  • Like
Reactions: cabotsolutions

Gryz

Golden Member
Aug 28, 2010
1,551
203
106
When someone wants to send email to somebody @ somedomain.com, the email-program does a DNS lookup for "somedomain.com". It doesn't do a usual DNS lookup. (Usually people/programs use DNS if they want to convert a name to an ip-address). The DNS has different types of information in it. Each piece of information is called a "Resource Record", aka RR.

A few example of different RRs are: A-records, which convert a name to an IPv4-address, AAAA-records, which convert a name to an IPv6-address, PTR-records, which convert an ip-address back to a name, etc. The type of RR you are interested in is called "MX-record". MX stands for "eMail eXchange".

So when someone wants to send email to "somedomain.com", he does a DNS-queury for "I want to know the MX-RR for somedomain.com". Maybe the answer will be "somedomain.com MX smtp.someprovider.com". The mail program now knows that it can send email for "somedomain.com" to a machine called smtp.someprovider.com. Next step is to do a query for an A-RR for "smtp.someprovider.com". So it knows the ipv4-address of the mail-relay it needs to send email to.

Still with me ?
You might have known this already.

The important fact for you is the fact that when RRs are sent (as replies to DNS queries, as explained above), each RR has a Time-To-Live field (aka TTL). Normally when a DNS server gives you a reply, the TTL is set to 1 or 2 days. This is the time that another DNS-server, or your homerouter that caches DNS, or the DNS-cache on your PC, may use that RR. After the RR has been in your DNS cache for 1 or 2 days, that device can not use that info anymore. In stead it needs to do a new query.

This is the source of your problem. Suppose someone sends email to you before the switch to your new provider. They ask "give me MX RR for "somedomain.com". They get their answer ("smtp.someprovider.com"). For the next two days, when they want to send email to you, they'll try sending it via "smtp.someprovider.com". If you switch to your new provider, the new provider will install a new MX record for "somedomain.com", which points to "smtp.newprovider.com". However, people who have sent email to you during the last 2 days, still have the old MX RR. And they'll keep trying to send email to you via "smtp.someprovider.com" in stead of "smtp.newprovider.com".

The trick is to adjust the TTL of the MX RRs.

You need to do this ahead of time.
Suppose you want to switch to newprovider.com. Suppose the TTL of your MX record at your old provider is set to 2 days. Ask your old provider to change the TTL of your MX RR to 1 hour. Do that 1 week before the switchover. Now you know that everyone that emails you before the switchover will keep your MX RR for at most an hour.
Now a few hours before the switchover, ask your provider to switch the MX RR's TTL to 5 minutes. Or 1 minute.

Now wait for the switchover.
The switchover is basically that your new provider asks the DNS registries to tell the root-servers to change their idea who to ask about your domain. The DNS registry will change something called a "NS RR" for your domain. The NS (NameServer) RR points to the machine that knows about your domain. Before your switchover if you'd ask a DNS server for ".com" about "somedomain.com", they'd answer "somedomain.com NS dns-server.someprovider.com". After the switchover, that server will now suddenly reply with "somedomain.com NS another-dns-server.newprovider.com".

After that happens, everybody on the net who wants to send you mail, will do a lookup for your MX-record, find a new NS RR for your domain, and a new MX RR for the smtp relay it needs to send email to.

After everything is working, and email goes to the right place, ask your new provider to change the TTL on all your records back from 1 or 5 minutes to 1 or 2 days.

I hope this explanation is a bit clear.
It is very straightforward. But it includes a few parties. You, your old provider, your new provider, and the DNS registry where your domainname is registered. However, change stuff like this happens more often. So you're not the first customer who asks for this. Ask your new provider to do this. Ask them for details and guidance. A switch-over with less than 1 or 5 minutes downtime is certainly possible. If they say they can't do it, you know they suck.

Edit: if you want to look at raw DNS data yourself, you should use a tool called: "nslookup".
It's easily available on Unix-variants, like Linux, FreeBSD, etc.
https://docs.oracle.com/cd/E19455-01/806-0625/6j9vfilsa/index.html
https://www.computerhope.com/unix/unslooku.htm

Maybe you could also use a web-page that is built around nslookup somewhere. But I don't have a good example of such a page. And you won't know what is cached and what is not cached. Better to use the simple thing: nslookup.

Hope this helps.
 
Last edited: