How to play nice with EasyDNS


#1

The client’s domain is registered at GoDaddy. The DNS is pointed to EasyDNS

At EasyDNS, the MX records are pointed to a third party, and the A record is pointed to the web host provider.

CloudFlare wants me to replace the EasyDNS with their CloudFlare’s DNS, but if I did this I would obviously take down everyone’s email and really annoy their IT person.

Is it possible to keep EasyDNS, and set up CloudFlare records there?
If so, would you please point me to reference.
If not, I’m not sure what to do.

Thank you,


#2

This article may be helpful for you.


#3

This is possible with plans that support CNAME configuration.

Moving to Cloudflare’s DNS should not cause their Mx records to fail assuming the records are imported properly though. We have thousands of domains move to Cloudflare daily and the goal is not to break existing infrastructure but to provide additional performance and security. www.dnsperf.com gives some indication of our performance vs some of the larger competitors.


#4

To clarify, and if I understand you correctly, there is NO option to continue to run the DNS through easyDNS.

In other words, in order to use CloudFlare the DNS MUST point to the CloudFlare DNS.

Is that correct?

Thank you


#5

Cloudflare would provide the same functionality as EasyDNS. You will get new IP addresses so visitors will still get content from GoDaddy via Cloudflare. The MX record will make sure email still goes to the email host.

The good news is you can go through the Setup process here and verify DNS records before you commit to using Cloudflare. Near the end of the process, it’ll tell you which name servers to use. You can pause at this point to compare your DNS records with what’s currently at EasyDNS. They should match.


#6

Thank you all - super helpful!


#7

There is the option to continue to use existing DNS with a plan which supports CNAME setup. I believe currently that is limited to business and enterprise plans. For free and Pro plans, changing DNS providers is required:


#8

Under the “measure twice, cut once” principal, I want to make sure that the steps I plan to deploy tonight are correct.
Would someone be able to put their eyes on this and let me know if I’m missing anything?

Background:
Domain is hosted at GoDaddy, and currently points to EasyDNS.
Email is hosted with MSFT O365.

In reviewing what Cloudflare shows for the DNS records, I see:
3 CNAME records for O365 show Automatic and grey clouds
1 MX record for domain.mail.protection.outlook.com which has no grey cloud
2 SRV records which have no grey cloud
1 TXT record MS=ms70964739 which has no grey cloud
1 TXT records for the SPF record which has no grey could

So, it’s my understanding that once I change the DNS at GoDaddy to point to the Cloudflare servers, I then need to log into Cloudflare and manually add in the MX, SRV, and TXT records.

Is that correct? If not, what is correct?
Thank you


#9

I appreciate the measure twice cut once attitude. :smiley:

  1. Doublecheck that all entries at EasyDNS (except perhaps ns entries specific to easyDNS if listed) exist in the Cloudflare DNS control panel.
  2. For any entries at EasyDNS which do not exist on Cloudflare either manually create the records or export a BIND file from EasyDNS and import into Cloudflare under the advanced tab.
  3. Double-check all the entries from EasyDNS exist in the Cloudflare UI (I doublechecked the ones you listed and at first glance appear as I would expect).
  4. Set all entries on Cloudflare to be gray clouded initially.
  5. Update nameservers at GoDaddy to the ones listed in your Cloudflare control panel (double-check the values before clicking to change).
  6. Wait for your SSL certificate to be issued by Cloudflare.
  7. Set any settings or page rules you want in place for Cloudflare.
  8. Orange cloud any records you wish to route through Cloudflare once the SSL cert has been issued.

#10

Thank you for the steps!

  1. check - all entries at EasyDNS appear in the Cloudflare control panel

  2. not necessary

  3. check

  4. Set all entries on Cloudflare to be gray clouded initially. I am stuck on this one. HOW do I set all entries to be gray clouded initially??

Specifically, I’m looking at this Cloudflare link: My-email-or-mail-stopped-working-What-should-I-do-
That resource says: When using Cloudflare, the MX record cannot be the domain itself, which passes through Cloudflare. A typical configuration to get around this: MX record is a subdomain with a grey cloud.

I don’t understand. Do I need to create a new record? If so, what should it be?

  1. check

  2. The A records points to the web host provider, which already has the SSL cert in place, and the site is already https. Will this cause a conflict?


#11

Please know that I have read dozens of articles in Support, and I. am. still. stuck.

The article below below explains why the Cloudflare DNS does not display a cloud for 5 of the clients records that relate to their O365 email.
But what should I do with the 5 records that have no cloud? In other words, how can I change the DNS tonight and not bring down 100+ email accounts?

The list of DNS records below do not display a cloud icon, and cannot run through the Cloudflare proxy.
LOC
MX
NS
SPF
TXT
SRV


#12

A good place to start is to use Cloudflare for your DNS, but all entries set to :grey: so Cloudflare isn’t proxying anything and your users are all connecting directly to the server. This behaves as a direct replacement for EasyDNS.

Those no-cloud DNS entries are, by nature, informational only. There’s nothing to proxy or route.

In all your information, I’ve seen no mention of an A record for your website’s IP address. Or a CNAME (for your website). Is that something you’re going to set up?

Based on your information, your MX record points to something at Office 365. If someone is using “example.com” for web and mail (MX), an :orange: server won’t respond to email connections, which is why email would stop working.


#13

Thanks for your response sdayman.
Here’s the rub: I can’t figure out how to set entries to a grey cloud, despite hours trolling through the support docs. The MX, SRV and TXT for O365 don’t show any cloud, so how do I change a no-cloud to a grey cloud?

The A record for the website is simple… I’ve got that.

It’s these O365 records that I can’t get a good handle on. I cannot risk taking down email for 100+ users. I must understand how this works - exactly - before I change any DNS records to point to CloudFlare.

Thanks again.


#14

In the case of MX, SRV, and TXT, consider it as being Grey. Again, it’s just an Info record. Like…“Hey, where do I send mail for example.com?” The MX record tells them “Send it to office365.com.” And then someone goes and looks up Office365.com to get its IP address.

So…if you get the MX record right, people will be able to send mail to your users. I’m betting your 100+ users have configured their mail clients to go directly to the mail server and will completely bypass any of your Cloudflare settings.


#15

OK, so let’s focus on the MX record. Right now Cloudflare DNS shows this:

Type: MX
Name: clientdomain.org (redacted)
Value: mail handled by clientdomain.org.mail.protection.outlook.com
There’s also an (0) (what does that mean?)
TTL: automatic
Status: NO CLOUD

Everything I’ve read says the MX record needs to be grey-clouded.
But I’ve got the no-grey-cloud blues… what to do?

There’s a country and western song in there somewhere…


#16

That’s good. Ultimately, DNS for your MX server is handled by outlook.com. As long as YOUR MX record tells emailers where your mail goes, you’re all set.

You can’t grey or orange cloud an MX record because it can’t be proxied. The 0 is the Priority, 0 being the highest. Other typical values are 5, 10, 20. If there was a backup MX host, it would get a 5 or 10.


#17

@danna sorry for the delay in responding… @sdayman has the right answer/ track. For those record types where we don’t offer a cloud option it’s because we’ll treat them as :grey: returnign the true value for the record.

Sorry know it can be a bit confusing, especially if you don’t spend all day thinking about DNS :nerd_face:

So I probably should have said “far any record which can be gray clouded, please make sure the cloud is gray until the SSL certificate is in place”.


#18

OK. I think I’ve got it. Which is to say, everything looks to be in place.
All I can do is change the DNS and hope for the best. Two last related questions:

On the Cloudflare DNS report the MX record shows a (0) rather than a (1). What does that mean?? Should I be concerned? Do I need to take any action?

The A record points to the web host provider, which already has the SSL cert in place for this domain, and the site is already https. Will two SSL certs cause a conflict? Do I need to take any action?


#19

An MX record is assigned a priority between 0 and uh… 64,xxx. The lowe the number the higher preference for the record to be used.

So an Mx record of 100 will be used before an Mx record of 200. The actual numbers chosen/used don’t matter at all 134 and 227 would result in the same priority order for a sending MTA, it will just choose the lowest numbered host and then fail back to higher numbered hosts if the lower number is unavailable. Hosts with the same priority (e.g. 10,10, 10) would be used in round robin fashion.

Because Microsoft runs a highly available MTA they only use a single Mx record (and generally speaking you shouldn’t have any other records) so the value used really has no impact.

By going gray cloud first we are going direct to your origin and not using the Cloudflare proxy. Once we issue you . universal SSL we (Cloudflare) will be the SSL termination endpoint for your end users. And by default you’ll be used our free/shared SSL cert. You can buy a dedicated one if you wish, but functionally there is little difference for most customers. You could also bring your existing cert on our business plan if you so desired.

You’ll want to choose full SSL between Cloudflare and your origin so we maintain SSL the whole way. You could also install a Cloudflare origin cert on your server if you wish, but it is not strictly necessary: https://support.cloudflare.com/hc/en-us/articles/218408028-How-to-install-an-Origin-CA-Certificate-Other-


#20

cscharff - Many thanks for the detailed explanation.

Now I understand that the (0) was simply the mx priority. I was thinking that (0) meant “problem” and (1) meant A-OK.

The cert that is on the site now is simply a free shared-server cert. After the DNS propagates, I can have it removed if needed.

All good lessons learned, but I hate learning on a big customer with high stakes.
Fingers crossed for a smooth propagation.