---
title: "Cloudflare DNS: from buying a domain to a working website"
description: "Choose a registrar, connect your domain, and understand the records behind your website and email. A practical Cloudflare DNS guide, with diagrams and troubleshooting commands."
author: "Omar Albeik"
date: 2026-09-17
type: tutorial
topics: [infrastructure]
language: en
reading_time_minutes: 17
canonical_url: https://omaralbeik.com/en/blog/series/cloudflare/understanding-cloudflare-dns
translation_url: https://omaralbeik.com/ar/blog/series/cloudflare/understanding-cloudflare-dns
source_url: https://omaralbeik.com/en/blog/series/cloudflare/understanding-cloudflare-dns.md
---
# Cloudflare DNS: from buying a domain to a working website
Moving DNS to Cloudflare lets you keep your website at its current host.
Moving the website itself is a separate choice. Understanding that
distinction makes the rest of the setup easier to follow.
This site runs on Workers. We'll use its public DNS records to follow a
request from the domain name to the application, then work through domain
registration, website and email setup, and troubleshooting. You don't need
a Cloudflare account to try the lookup commands.
The guide uses Cloudflare's standard setup for a public website, with a
short section on alternative DNS arrangements near the end.
If you're returning with a particular job in mind:
- [Choose a registrar](#is-cloudflare-a-good-place-to-buy-the-domain).
- [Set up an existing domain](#move-dns-to-cloudflare).
- [Read and add records](#read-the-record-before-you-edit-it).
- [Connect the website](#connect-the-name-to-the-application) or [email](#keep-email-working-too).
- [Understand caching](#why-a-dns-change-takes-time) or [diagnose a problem](#check-dns-then-check-http).
## Who answers for your domain?
The registrar is where you register and renew a domain. Its nameserver
settings tell the rest of the DNS system which servers are responsible for
the domain's records. Those are its **authoritative nameservers**. The host
is where the website runs. These jobs can belong to different companies.
When your browser needs an address, a DNS resolver looks it up. That resolver
may already have a cached answer; otherwise it follows the DNS hierarchy to
find the authoritative servers. Cloudflare's
[DNS walkthrough](https://www.cloudflare.com/learning/dns/what-is-dns/)
explains that lookup in more detail.
For `www.example.com`, the root servers can refer the resolver to the
servers for `.com`. Those can point it to the nameservers for `example.com`,
which answer for `www`. The resolver does the searching; the browser doesn't
visit each nameserver itself. Cached answers can skip much of this work.
Cloudflare has two roles here that are easy to confuse. Its public resolver,
[1.1.1.1](https://developers.cloudflare.com/1.1.1.1/), looks up names for clients. Its authoritative DNS service
answers for domains managed on Cloudflare. Using 1.1.1.1 on your laptop
neither moves your domain to Cloudflare nor turns on the orange cloud.
The records you manage together for a domain form a **zone**. The zone's
root, or **apex**, is `example.com`; `www.example.com` is a subdomain. The
`/articles` part of a URL belongs to HTTP routing. DNS never chooses which
article to show.
Here is a small piece of this site's setup you can check from a terminal
with `dig` installed:
```bash
dig +short NS omaralbeik.com
```
When I checked on September 17, 2026, it returned:
```text
alan.ns.cloudflare.com.
demi.ns.cloudflare.com.
```
That tells us Cloudflare provides the authoritative DNS. It doesn't tell us
who registered the domain or where the application runs. A site on a rented
server could give the same kind of answer.
## Is Cloudflare a good place to buy the domain?
If you already want Cloudflare to manage DNS, its Registrar is a good
option to consider. You may keep the name for years, so renewal pricing
and everyday administration matter as much as the purchase itself.
[Cloudflare Registrar](https://developers.cloudflare.com/registrar/) charges
registry and ICANN costs without adding a markup, for both registration and
renewal. Compare the renewal price as well as the first-year offer when
shopping around. At-cost pricing doesn't mean a price frozen forever:
underlying registry charges can change, and it doesn't guarantee the lowest
promotional price at every moment.
There are practical benefits beyond price:
- Registration and DNS live in the same account, so there is less switching
between dashboards when you connect a service.
- DNSSEC activation is integrated with the registrar, avoiding the manual
transfer of DS values between providers.
- [Personal contact details are redacted](https://developers.cloudflare.com/registrar/account-options/whois-redaction/)
from public registration records where registry rules permit. This isn't
anonymity: Cloudflare still needs accurate registration details, and
some fields remain public.
**The tradeoff is nameserver choice.** A domain registered at Cloudflare
[must use Cloudflare's nameservers](https://developers.cloudflare.com/registrar/get-started/register-domain/).
You can host the website elsewhere, but you can't switch the domain to
another provider's nameservers while keeping Cloudflare as its registrar.
If that flexibility matters, register elsewhere and use Cloudflare for DNS.
Also check the [supported extensions](https://developers.cloudflare.com/registrar/top-level-domains/)
before committing to a name. Cloudflare Registrar currently doesn't support
internationalized domain names, including Arabic-script names or their
Punycode equivalents. That is a Registrar restriction, not a statement
that DNS itself is limited to English names.
### Buying a new domain
In **Domain Registration → Register Domains**, search for the name, check
the registration period and renewal terms, and enter accurate contact
information. Review the total before completing the purchase. Then complete
email verification and check auto-renewal and your payment method. The
[registration guide](https://developers.cloudflare.com/registrar/get-started/register-domain/)
explains the current flow; auto-renewal is enabled by default.
Your new domain uses Cloudflare nameservers already. You still need to
connect the website and email. Buying the name doesn't deploy an application
or create a mailbox.
### Bringing an existing registration
You can move DNS without transferring registration. If you do want to
[transfer registration to Cloudflare](https://developers.cloudflare.com/registrar/get-started/transfer-domain-to-cloudflare/),
first make the zone active on Cloudflare. Check transfer eligibility and
follow the instructions for your extension. For most generic TLDs, this
means unlocking the domain and obtaining an authorization code from its
current registrar. Recent registrations, transfers, or contact
changes may trigger transfer locks. The fee and any extra registration
period depend on the extension; don't assume every TLD follows `.com` rules.
## What the orange cloud changes
For a site hosted elsewhere, Cloudflare's
[proxy setting](https://developers.cloudflare.com/dns/proxy-status/)
decides whether web traffic passes through its network. With **DNS only**,
the lookup exposes the hosting destination and the browser connects there.
With **Proxied**, the answer contains Cloudflare addresses, and the browser
connects to Cloudflare first. This is where its HTTP security and caching
features can act on the request.
The orange cloud doesn't mean every response is now cached. Cloudflare's
ordinary CDN [doesn't cache HTML or JSON by default](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/).
Workers and static assets have their own delivery behavior, which we'll get
to in the hosting installment.
Nor is that toggle a general-purpose proxy for every protocol. Keep mail
server records and third-party ownership-verification records DNS-only;
follow the service provider's instructions. Cloudflare documents the
[proxy's limits](https://developers.cloudflare.com/dns/proxy-status/limitations/)
separately from its DNS service. `A`, `AAAA`, and `CNAME` records can be
proxied when used for supported traffic; `MX` and `TXT` cannot be proxied.
For a proxied external origin, the public answer hides the configured
origin address, but that alone doesn't make the origin inaccessible.
[Other DNS-only names](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/exposed-ip-address/)
or historical records may reveal it. Protecting direct
access to the server is a separate hosting decision.
## Read the record before you edit it
The records you'll meet most often each answer a different question. This
is the short version of Cloudflare's
[record-type reference](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/):
| Record | What it supplies |
| --- | --- |
| `A` | An IPv4 address for a name |
| `AAAA` | An IPv6 address for a name |
| `CNAME` | Another hostname to resolve |
| `MX` | The mail servers that receive email for the domain |
| `TXT` | Text used for purposes such as ownership checks and email authentication |
| `CAA` | Which certificate authorities may issue certificates for the name |
| `SRV` | A service location, including its host and port |
| `NS` | The nameservers responsible for a zone or delegated subdomain |
| `PTR` | A reverse lookup from IP address to name, usually managed by the IP provider |
To add one, open your domain's **DNS → Records → Add record**. Choose the
type, name, and content, then the proxy status and TTL where applicable.
The [record editor](https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/)
also supports comments. Note which service requested the record so you can
identify it later.
Suppose a host asks you to create a CNAME for `www.example.com`, pointing to
`project.host.example`. The value is that hostname, without `https://` or a
path. The host also needs to recognize `www.example.com` as a name it serves.
DNS alone doesn't configure the application at the other end.
It doesn't redirect the browser, either. A CNAME from `www` to the bare
domain leaves `www` in the address bar. To choose one public address and send
visitors there, configure an HTTP redirect on your host or at Cloudflare.
You may see `@` in the dashboard: it means the zone's root, such as
`example.com`. Cloudflare can also use
[CNAME flattening](https://developers.cloudflare.com/dns/cname-flattening/)
to return a target's IP addresses, including for a CNAME at that root.
Consequently, an address returned by `dig` doesn't necessarily reveal the
record type you entered in the dashboard.
For an ordinary hostname, don't add a CNAME alongside an A or AAAA record
with the same name. Cloudflare rejects these
[conflicting records](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/records-with-same-name/).
An A and an AAAA can coexist: they answer different address-family queries.
Only add an origin AAAA record when that server serves the site over IPv6.
For DNS-only names, an old AAAA can send IPv6 visitors to the previous host
while your IPv4 test succeeds. For proxied names, Cloudflare can
[advertise its own IPv6 addresses](https://developers.cloudflare.com/network/ipv6-compatibility/)
even when your origin uses IPv4; you don't need an origin AAAA for that.
## Move DNS to Cloudflare
For a domain registered elsewhere, use Cloudflare's
[full setup](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/).
[DNS is available on the Free plan](https://developers.cloudflare.com/dns/);
domain registration and any paid products are separate costs.
Work through the move in this order:
1. Save a copy of the records at your current DNS provider.
2. Add the root domain to Cloudflare and compare the imported records with
that copy; the automatic scan can miss entries. Include the website,
mail, verification, and less-used names.
3. Handle existing DNSSEC before switching, as described below.
4. At the registrar, replace the old nameservers with the exact pair assigned
to this zone. Don't copy the pair from my site's example.
5. Keep the old DNS service and hosting available during the transition.
Check that Cloudflare marks the zone **Active**, then test the services.
Adding NS records inside the old DNS dashboard isn't a substitute for
changing the registrar's nameserver setting. The delegation at the parent
zone is what sends resolvers to the new provider.
If DNSSEC is already enabled, follow the
[DNSSEC migration procedure](https://developers.cloudflare.com/dns/dnssec/#migrate-to-cloudflare-with-dnssec-active)
before the switch. In the standard migration, remove the old DS record at
the registrar and allow its cached copies to expire before changing
nameservers. Keep the old zone signed while cached DS records remain valid.
After the switch, wait for the old nameserver records' TTL to expire before
enabling DNSSEC at Cloudflare and publishing its new DS record. This avoids
validating resolvers pairing one provider's keys with the other's answers.
The procedure leaves a temporary gap in DNSSEC protection; the linked guide
also covers migration with continuous signing for providers that support it.
### What DNSSEC actually protects
DNSSEC uses signatures and a chain of trust through the parent zone to let
validating resolvers check the origin and integrity of DNS answers. It
doesn't encrypt queries or replace HTTPS.
[DNS over HTTPS](https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/)
encrypts the connection between a client and its resolver.
For a new Cloudflare zone, open **DNS → Settings → DNSSEC** and follow the
activation instructions. The DS record links the parent zone to your DNS
signing key. With an external registrar, publish the DS values
Cloudflare supplies at that registrar. With Cloudflare Registrar, the
integration handles that part. Confirm the resulting status rather than
assuming the switch alone completed the chain.
If you later move DNS away, plan DNSSEC again. A DS record still pointing
to the old keys can break resolution even when every A and MX record has
been copied correctly.
## Connect the name to the application
For an external host, use the DNS values it supplies and confirm whether it
supports Cloudflare proxying. Don't copy another site's public IP address:
with a proxied site, that may simply be a Cloudflare address.
For example, a host might supply an IPv4 address for the root name and
ask for `www` to alias it. Add the A record for `@`, the CNAME for `www`,
and register both names in the hosting service. Choose a canonical hostname
and configure the redirect there, or use Cloudflare
[Redirect Rules](https://developers.cloudflare.com/rules/url-forwarding/).
A Cloudflare redirect requires the source hostname's traffic to reach its
proxy. Test both names over HTTPS; DNS, certificate coverage, and redirects
all need to agree.
For an application running on Workers, a
[Custom Domain](https://developers.cloudflare.com/workers/configuration/routing/custom-domains/)
connects a hostname directly to the Worker. With an active Cloudflare zone
and an existing Worker, open the Worker's **Settings → Domains & Routes →
Add → Custom Domain**. Cloudflare creates the DNS record and certificate.
An existing CNAME at that hostname must be resolved before adding it; check
what it serves before replacing it.
A Custom Domain matches the hostname exactly. Attaching `example.com`
doesn't attach `www.example.com`; account for both if you want both to work.
This is different from a Worker Route, which can run code in front of an
existing origin. We'll use that distinction in the next installment.
For an external server behind the proxy, HTTPS also has two connections:
browser to Cloudflare, then Cloudflare to the server. Use
[Full (strict)](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/)
with an unexpired, hostname-matching certificate issued by a publicly
trusted authority or Cloudflare Origin CA. In DNS-only mode, the browser
connects to your host directly and needs a publicly trusted certificate;
[Cloudflare Origin CA certificates aren't trusted by browsers](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/#3-change-ssltls-mode).
Cloudflare's standard
[Universal SSL coverage](https://developers.cloudflare.com/ssl/edge-certificates/universal-ssl/limitations/)
on a full zone includes the apex and first-level subdomains. Don't assume
it also covers `api.staging.example.com`. A DNS record can resolve perfectly
while that deeper hostname needs additional certificate coverage.
## Keep email working too
Your website and email can use different providers. Keep the
[email records](https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/)
supplied by your mail provider when you change DNS.
MX records identify the receiving mail servers; lower priority numbers are
preferred. If an MX points to `mail.example.com`, that name needs an address
record too, and that mail-server address should stay DNS-only. Cloudflare's
normal web proxy doesn't carry SMTP traffic.
Sending mail brings three more names into the dashboard:
- **SPF** uses a TXT record to authorize sending servers for the SMTP
envelope-sender domain, which can differ from the visible From address.
Your provider specifies whether to publish it at `@` or a subdomain.
- **DKIM** publishes the information receivers use to verify a message's
signature. Providers often supply TXT or CNAME records under
`selector._domainkey`.
- **DMARC**, published as TXT under `_dmarc`, requests handling and reports
for mail using your visible From domain. A
[DMARC pass](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.1)
requires SPF or DKIM to pass with a domain aligned to that From domain;
one aligned pass is enough.
Use the provider's actual values. Don't copy a mail policy from an unrelated
site, and don't publish a separate SPF policy for each sending service:
[SPF permits one policy record per name](https://www.rfc-editor.org/rfc/rfc7208#section-3.2).
Combine authorized senders according to your providers' instructions. Work
out all legitimate sending services before enforcing a strict DMARC policy.
An ownership-check CNAME should usually remain DNS-only. Disable any
optional per-record flattening and the zone-wide “flatten all” setting.
Some services need to see the CNAME itself, not its target's IP address.
Cloudflare's
[verification troubleshooting guide](https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/cname-domain-verification/)
explains why an apparently correct record can fail that check.
Publishing these records doesn't create a mailbox. Cloudflare Email Routing
and application email are separate services; we'll cover those in the email
installment.
## Why a DNS change takes time
A DNS edit updates the authoritative answer. It doesn't push a notification
to every resolver, phone, and browser that has an older answer cached.
During this period, often called “propagation,” clients may use different
copies of the answer.
For a planned DNS-only address change, lower its TTL in advance and allow
the previous TTL to pass before moving the service. Keep both destinations
working during the transition where possible. Cloudflare's proxied records
use [Auto TTL, currently 300 seconds](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/),
which isn't an end-to-end promise that every client will see a change within
five minutes. Delegation and local caches have their own lifetimes.
Also distinguish DNS caching from caching a page. Purging Cloudflare's CDN
cache doesn't clear a resolver's DNS cache. If the hostname reaches the
right application but displays an old article, inspect HTTP caching and the
deployment before changing DNS.
## Check DNS, then check HTTP
Back to this website. Query its addresses:
```bash
dig +short A omaralbeik.com
dig +short AAAA omaralbeik.com
```
At the same check on September 17, the A query returned `188.114.96.0` and
`188.114.97.0`. Treat these as an observation, not configuration values to
copy. DNS shows where a client can connect; it won't identify my Worker or
show how the application handles `/en` and `/ar`.
To inspect the HTTP response, ask for its headers:
```bash
curl -I https://omaralbeik.com/en
```
A response with `server: cloudflare` and a `cf-ray` header gives you evidence
that Cloudflare handled the request. It doesn't establish a cache hit.
Read the status code too: a redirect is a valid HTTP response, but the page
you want is at the destination in its `location` header.
When a changed record seems stuck, compare a recursive resolver's answer
with an authoritative answer. For this site's nameservers at the time of
writing:
```bash
dig @1.1.1.1 omaralbeik.com A +noall +answer
dig @alan.ns.cloudflare.com omaralbeik.com A +noall +answer
```
For your own domain, substitute its name and one of its assigned
nameservers. The number before `IN A` is the answer's TTL in seconds.
Proxied responses may contain different Cloudflare addresses; unequal IPs
alone don't prove stale data. DNS won't expose a proxied origin change,
so check the configured destination in the dashboard and test HTTP too.
If `+short` prints nothing, repeat the query without it. An empty answer
isn't a diagnosis: the full response distinguishes an absent record from
errors such as `NXDOMAIN` or `SERVFAIL`. If DNS resolves but HTTPS fails,
move on to certificates, routing, and the application.
### Match the symptom to the next check
| What you see | Where to look next |
| --- | --- |
| Zone stays Pending | The registrar's assigned nameservers and existing DNSSEC delegation |
| `NXDOMAIN` | Spelling, the selected zone, and whether that name exists at the authoritative provider |
| `NOERROR` with no answer | Whether the queried record type exists; an empty AAAA answer need not mean the A record is broken |
| `SERVFAIL` | DNSSEC validation, delegation, and nameserver availability; it isn't proof of a DNSSEC fault by itself |
| Some visitors reach the old host | Cached answers and any A/AAAA records still pointing at the old destination |
| DNS works, HTTPS fails | Certificate coverage, proxy mode, origin TLS, and the host's domain configuration |
| Homepage works, email fails | MX destinations, mail-server address records, and authentication records |
| Ownership check fails | Exact record name, CNAME proxy/flattening settings, and any subdomain delegation |
These are starting points, not diagnoses. Keep the full command output
before changing settings so you can tell whether the next change helped.
You can also inspect the delegation chain with:
```bash
dig +trace omaralbeik.com
```
That follows referrals rather than relying on your usual recursive resolver.
It can fail on networks that block direct DNS queries; that failure alone
doesn't establish that the website is broken.
## Wildcards, delegation, and other setups
**Wildcards** such as `*.example.com` can supply answers for otherwise
unmatched subdomains. They don't replace the apex record, and an existing
name or delegation can stop wildcard matching. Cloudflare's
[wildcard examples](https://developers.cloudflare.com/dns/manage-dns-records/reference/wildcard-dns-records/)
cover the less obvious cases, including deeper labels. DNS wildcard matching
and certificate wildcard coverage are different rules; don't infer one
from the other.
**Subdomain delegation** gives another DNS provider responsibility for a
branch such as `team.example.com`. Add the provider's NS records for `team`
in the parent zone; manage that branch's records at the delegated provider.
This is different from simply creating an A record for a subdomain. Follow
[the delegation guide](https://developers.cloudflare.com/dns/manage-dns-records/how-to/subdomains-outside-cloudflare/)
if that branch also needs DNSSEC.
**Partial and secondary setups** serve organizations with existing DNS
requirements. A partial CNAME setup lets eligible Business or Enterprise
zones retain another authoritative provider while proxying selected names.
Enterprise zone transfers support primary or secondary DNS arrangements.
These are [alternative setups](https://developers.cloudflare.com/dns/zone-setups/),
not steps required to connect an ordinary website.
## Leave yourself a setup you can maintain
Before a substantial edit, export the zone from **DNS → Records → Import
and Export**. Cloudflare's
[zone-file export](https://developers.cloudflare.com/dns/manage-dns-records/how-to/import-and-export/)
includes record data and Cloudflare-specific tags. Keep a separate note of
settings outside DNS, such as redirects, TLS, and Worker domains; the zone
file isn't a backup of the whole account.
For automated updates, use a scoped
[API token](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/)
with only the DNS permissions and zone the job needs. A read-only inventory
shouldn't have permission to rewrite your domain. Store the token as a
secret, and make the same record changes through one maintained workflow
rather than competing dashboard edits and scripts.
Finally, check the things a visitor actually uses: the apex and `www`, their
HTTPS certificates, the preferred redirect, and email in both directions.
Confirm DNSSEC and renewal settings too.
Next we'll look inside the Worker that receives the request.
Know someone connecting their first domain? Share this guide with them. If
your setup behaves differently,
[send me the symptom and what you checked](/en/contact).