Module 7 · 7.5
Your DNS with another provider, such as Cloudflare
Module 7: Connecting external services · Reading time: 9 minutes
Learning objective: After this lesson you'll be able to move your domain's DNS to an external DNS provider, know which records to bring across, and how to deal with a proxy.
Key concepts: external nameservers, taking over a zone, records that need to come across (A, AAAA, MX, SPF, DKIM, DMARC, subdomains, verifications), proxy (orange and grey cloud), certificate behind a proxy (Full strict), CNAME flattening
Why your DNS might be elsewhere
You might have your website with one provider, your email with a second, and your DNS with a third. People choose a separate DNS provider for example because they want all their domains in one place, for extra features (such as a proxy that blocks attacks), or because their web developer sets it up that way. Cloudflare is a well-known example of this, but it works the same way with any external DNS provider.
You know the principle from lesson 2.1: whoever runs the nameservers manages the DNS. If you point the nameservers to another provider, the records at your previous DNS manager no longer count. Not even if your web host or mail provider still has everything neatly set up there.
The order: set up first, then switch
- Make an overview of your current zone. Export it, make a backup in your panel, or take screenshots of all the records (lesson 6.3).
- Set up all the records at the new provider. Many providers automatically read in your existing records. That's handy, but not complete: they only find names they can guess. Records such as
x._domainkey,_dmarc, verification TXT records on subdomains, or anautodiscoverare often missed. So compare against your overview from step 1. - Lower the TTL in advance if needed at your current provider (lesson 6.3).
- Change the nameservers at your registrar to the nameservers provided by the new provider.
- Check after the switch that the website, email and certificate work, and that the new provider sees the nameservers as active.
Some registries, such as DENIC for .de, check during a nameserver change whether your domain is already set up on the new nameservers. If the zone isn't there yet, they refuse the change. This is another reason to set things up first.
Which records need to come across?
A checklist for a domain with a website and email. Copy the values from your web host and your mail provider.
| Type | Name | What it's for | What happens if you forget it |
|---|---|---|---|
| A and AAAA | @ | your website | website unreachable |
| A, AAAA or CNAME | www | your website with www | www. doesn't work |
| A | mail (or the name your provider uses) | your mail server | mail program can't find the server; MX pointing to mail doesn't work |
| MX | @ | incoming mail | you don't receive mail |
| TXT | @ | SPF, and verification codes | mail ends up in spam more often; services lose their verification |
| TXT or CNAME | <selector>._domainkey | DKIM | DKIM fails, mail ends up in spam more often or is rejected |
| TXT | _dmarc | DMARC | no DMARC policy any more |
| CNAME | autodiscover | Outlook settings (Microsoft 365) | Outlook can't find the settings |
| SRV, CAA | various | telephony, Teams, certificates | service doesn't work, or certificate is refused |
| A or CNAME | each subdomain (shop, cloud, test) | subdomains | subdomain unreachable |
Watch out for subdomains you created in your hosting panel. With your web host's DNS, these often ended up in the zone automatically, or worked via a wildcard (*). With an external provider you need to create them yourself, or set up a wildcard yourself (lesson 3.3). If you create a new subdomain in your hosting panel later, add it to the DNS provider too.
And the DKIM key from your web host: this is in the zone at your web host, for example as x._domainkey. Copy the name and the whole value to the new provider. A common mistake is that the value gets cut off or spaces get added along the way.
The proxy: orange or grey
Cloudflare and similar services have a proxy alongside DNS. At Cloudflare you see this as a cloud icon behind each A, AAAA and CNAME record:
- Orange (proxied): the DNS doesn't return your server's IP address, but an address belonging to Cloudflare. Visitors go to Cloudflare first, and Cloudflare forwards the request to your server. This only works for websites (http and https).
- Grey (DNS only): the DNS simply returns the real IP address. Cloudflare then only does DNS.
Consequences:
- Mail doesn't go through the proxy. Set the record for
mailand anything your mail program or other mail servers use to grey. Ifmailis set to orange, your MX points to a Cloudflare address that doesn't accept mail. - FTP, SSH and other non-web traffic also don't go through the proxy. Use a name with a grey cloud for these, or your web host's server name.
- Certificates. With orange, a certificate issuer such as Let's Encrypt doesn't see your server directly. Automatically requesting a certificate at your web host can then fail. Temporarily set the proxy to grey until your web host has the certificate, or use a method that works via DNS.
- SSL mode. Set the SSL mode in Cloudflare to Full (strict) if your server has a valid certificate. In "Flexible" mode, traffic between Cloudflare and your server is not encrypted, and this mode also often causes an endless redirect loop on websites that already redirect to https themselves.
CNAME on the bare domain?
A regular CNAME on @ isn't possible (lesson 3.2). Some DNS providers offer a solution for this, under names such as CNAME flattening, ALIAS or ANAME. You enter a name for @, and the DNS provider looks up the corresponding IP address itself and returns that as an A or AAAA record. So to the outside world, there's simply an A record.
This is handy if a platform only gives you a name. But it's not standard DNS: if you move to a provider that doesn't support it, you'll need to create an A record with an IP address again.
Recognising problems
- "I've changed a record and nothing happens." Check which nameservers your domain uses (lesson 8.2). If they're at the external provider, change the record there.
- Website works, mail doesn't. Is the MX missing, is the A record for
mailmissing, or ismailset to orange? - Mail arrives, but more often in spam. DKIM record forgotten or cut off, or SPF not copied across.
- Certificate error or redirect loop. Proxy on with SSL mode Flexible, or your web host couldn't request a certificate.
In practice: what this looks like in a panel
In the example panel My WebOké, you can see at the top of the DNS tab which nameservers your domain uses. If external nameservers are shown there, changes in My WebOké or DirectAdmin have no effect. The values you need at the external provider (IP address, server name for the MX, DKIM key at x._domainkey) can be found in DNS Administration in DirectAdmin or in your package's welcome email. You change the nameservers on the domain page at the Nameservers card.
In other panels, such as cPanel, Plesk or your registrar's DNS screen, you'll see the same records. At the external provider the buttons are named differently, but you fill in the same fields: name, type, value, TTL, and at Cloudflare the proxy mode.
Summary
- Whoever runs the nameservers manages the DNS. Records at your previous provider no longer count.
- Set up all the records at the new provider first and compare against an overview of your old zone; then switch the nameservers.
- Don't forget:
mail, MX, SPF, DKIM (x._domainkey), DMARC,autodiscover, verifications and subdomains. - Mail and other non-web traffic don't go through a proxy: set those records to "DNS only" (grey).
- Use SSL mode Full (strict) with a proxy. CNAME flattening only works at providers that offer it.
Quiz
Exercise
Exercise Z7.5: Recognising external DNS.
- Find the nameservers for
cloudflare.com. Which domain do they end in? - Find the A records for
cloudflare.com. Write down one A record. These are addresses belonging to Cloudflare itself: this is how a proxy works. - Choose a domain you know (your own domain is fine). Look up the nameservers and enter the domain name and the nameservers. The names of the nameservers show you which provider manages the DNS.
The check will look up the records live when you submit.
Further reading
These pages describe the steps in WebOké's panels (DirectAdmin and My WebOké). In other panels it works the same way.
- Use your own or external nameservers (such as Cloudflare) for your domain
- Setting up DKIM when DNS is hosted on an external server
- DirectAdmin guide 5.12: DNS in My WebOké and with external name servers such as Cloudflare
- WebOké manual 5.3: Edit nameservers
- DirectAdmin guide 6.6: Let's Encrypt not working: causes and solutions
