|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
10 Aug 2017, 05:39 AM | #1 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
How to handle DNS with Fastmail and (different) web host?
I use FM for email with my own domain. I also have a website using the same domain but hosted by an outside (not FM) webhost.
Currently I have DNS delegated to nameservers at my web host and then manually set MX records there pointing to FM for email. Alternatively, one could delegate DNS to FM's nameservers and then set an A record to point to the IP address of my web site. What are the advantages/disadvantages of each approach? 6 of one, half dozen of another? Or are there some specific reasons to prefer one over the other? |
10 Aug 2017, 09:26 AM | #2 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
If you can tolerate a small risk that a service failure makes rapid recovery from the problem impossible, it really does not matter. However, for those requiring a robust solution that is resilient against failure of a single service, I have long recommended the following.
Having registered your domain, park the DNS at a separate DNS management host (such as EasyDNS or ZoneEdit). The reason for the separation is that, should your DNS host fail, or be otherwise inappropriate for further use, you can use the site where you registered the domain to change to a new DNS host. If your domain registrar fails, this will not impact your DNS in the short term. One assumes there would be ways in the long term to establish your domain with a new registrar. None of your websites, mail servers and other services are hosted at your domain registrar or DNS host. As a result, if any mail server or web host fails, you have the ability within a few hours, to establish the service elsewhere should you encounter a failure that you judge cannot be circumvented in another manner. The above is not the simplest solution, but it avoids single points of failure that leave you without recourse. Some will be so confident of their provider that they may choose to register the domain and host all services in the same place. They are entitled to their opinion, but experience has made me very leery of assuming a single vendor deserves that much trust. The simplicity of that approach would appeal to me only for domains with services that I do not regard as mission critical. |
10 Aug 2017, 10:40 AM | #3 | |
The "e" in e-mail
Join Date: Feb 2002
Posts: 2,937
|
Quote:
|
|
10 Aug 2017, 11:23 AM | #4 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
I take your point about "skin in the game", and I actually pay a small amount to my DNS hosts for 5-nines reliability. There is some value in using a specialist DNS management organization over a mail service that dabbles in DNS support. I am a firm believer in the "best of breed" principle. |
|
10 Aug 2017, 03:27 PM | #5 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,929
|
I agree that for critical business needs you should look for the best DNS host available. But so far I have had very good reliability with the free (for a Standard or better account) Fastmail DNS hosting. I also find it very easy to set up the DNS records needed for email and simple websites, since Fastmail automatically sets up:
|
11 Aug 2017, 12:06 AM | #6 |
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
I've gone back and forth on this a bit over the years, and really I mostly agree with what Bill says about FastMail's simplicity in that they configure all of the records for you, making it really easy to get everything up and running, especially if you're not experienced in the ways of DNS — there are more records to deal with for an e-mail service than for a simple web host (as you can see from Bill's list above), so this is where FastMail excels.
Further, while BritTim's point about having to find another DNS provider in the event of failure is valid, depending on your registrar this may not be as big of an issue. EasyDNS, for example, offers basic DNS hosting with every domain registration, so if FastMail were to suffer a catastrophic failure, you could simply point your NS records back to the registrar and use them. In my case, I've used FastMail off and on in the past but I've also gone back over to DynDNS, simply because they're "best of breed" for DNS hosting and I have the benefit of being grandfathered in on their standard DNS plan from when they were offering services for one-time payments about 15 years ago so it's completely free. Were that option not available to me, however, I'd likely just stay with FastMail's DNS. |
11 Aug 2017, 12:11 AM | #7 | ||
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
Quote:
|
||
11 Aug 2017, 02:31 AM | #8 | ||
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
Code:
"v=spf1 +a +mx +ip4:129.121.176.191 +ip4:108.165.20.5 +include:relay.mailchannels.net +include:spf.messagingengine.com ~all" Two questions remain:
Thanks to all who replied to my initial question! |
||
11 Aug 2017, 03:02 AM | #9 | |||
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
On the flip side, if you do have a valid reason to use that SPF record, you'll need to disable FastMail's default SPF record and add that back in manually in your DNS setup at FastMail. Quote:
Code:
v=spf1 include:spf.messagingengine.com ?all A more restrictive SPF record for sending messages through FastMail only would simply replace the "?all" with "-all" resulting in this: Code:
v=spf1 include:spf.messagingengine.com -all To break it down, SPF records designate which servers are allowed to send mail on behalf of your domain, DKIM records contain the key used to "sign" messages from your domain, and DMARC records tell receiving servers what you want them to do if a message from your domain fails to match either the SPF or DKIM records. Note that you can also use ~all, which is considered a "soft fail" —*again how this is handled depends on the receiving system, but it generally indicates that messages that fail the SPF record are more likely to be categorized as spam (given a slightly higher score), and be reported on, but less likely to be rejected outright. Quote:
|
|||
11 Aug 2017, 05:53 AM | #10 | |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
That SPF record was added at the zone record for my domain at my webhost, who handles my name servers. The two IP addresses reverse DNS lookup to the web host's domain (asmallorange.com). The entry for messagingengine.com was added automatically by the web host, probably because I had manually added MX records pointing to FM. "mailchannels.net" is a service used by my webhost to handle part of their email security. As far as sending mail through non-FM SMTP servers is concerned, I'd certainly rather not! But, there were historical reasons why I had to. When I first got an iPhone, FM didn't have an iOS app, and the mail app built into iOS handles IMAP in a way that was very user unfriendly (I have lots of folders set up, and navigating back and forth within the iOS app to look at specific IMAP folders is a pain!). So, I had all email sent to mydomain.com forwarded by FM to a Gmail address, and then I used the iOS mail app to read all email via the Gmail inbox. I was able to set things up at Gmail to use an address at mydomain.com as the "From" address, and I could set things up so that Gmail used the FM SMTP server, but the net effect of this was that whenever I used the "share" button on my iPhone to send a link or something else, the iPhone would use the Gmail SMTP server and not the FM server. I never did figure out a way to work around that. BUT, now that FM has an iOS app, I don't have a Gmail account set up on the iPhone, so all email gets sent out via the FM server. |
|
11 Aug 2017, 06:34 AM | #11 |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
How to set up the right A records at Fastmail...
So, now the question is how to set up the A records at FM for my non-FM website so that things work. As I look at the Zone records for my domain at my web host, I have a lot of A records, for things like subdomains as well as ftp. What I have noticed is that all of those A records all point to the same IP address. So, I'm thinking all I should have to do is to have two A records at FM, as follows:
mydomain.com IN A xxx.xxx.xxx.xxx (where xxx.xxx.xxx.xxx is the IP address of the web host) *.mydomain.com IN A xxx.xxx.xxx.xxx The second is to handle ftp, subdomains, www., etc. Can it be this simple? |
11 Aug 2017, 06:40 AM | #12 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Avoid wildcard DNS records unless you are an expert. They do not work the way most people expect.
Use either separate A records or separate CNAME records. Even if there are many of them, it only takes a couple of minutes to set them all up |
11 Aug 2017, 09:22 AM | #13 | |
Cornerstone of the Community
Join Date: Jul 2002
Location: Tacoma, WA
Posts: 642
|
Quote:
Aside from the additional lookup time, is there a functional difference I should care about between: Code:
mydomain.com A ip addr ftp.mydomain.com A same ip addr Code:
mydomain.com A ip addr ftp.mydomain.com CNAME mydomain.com |
|
11 Aug 2017, 10:30 AM | #14 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
One thing you should never do, unless following instructions of your service provider in very unusual situations, is to CNAME your root domain to another domain. Use an A record for the root domain unless quite sure a CNAME is correct. I have seen CNAME records appear to work for a while and then result in very strange behavior in this case. |
|
11 Aug 2017, 10:51 AM | #15 | |
Essential Contributor
Join Date: Apr 2008
Posts: 371
|
Quote:
CNAME records are simply not permitted at the root domain level for all practical purposes. Technically speaking, as per RFC 1034, the only scenario in which a CNAME record at the root level would ever be acceptable is in the scenario where you have NO other resource records in that particular domain, which would be an extremely rare and specific situation. For the same reason, you should never use a CNAME record in conjunction with any other records. So, don't use a CNAME and an A record for the same hostname (e.g. www.mydomain.com). In short, if you're using a CNAME record for a given entry, it should be the only record for that entry. It's also best to avoid using CNAMEs as targets of other record types. This is especially true for MX and NS records (e.g. you can't have an MX pointing to a CNAME — MX records should always point to A records), but it can be an issue with other record types as well. |
|