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.
• Set up an existing domain.
• Read and add records.
• Connect the website or email.
• Understand caching or diagnose a problem.

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 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.

How the resolver finds an answer

An uncached lookup: the browser asks its resolver, which makes these queries.

1. 01 · RootRoot nameserverRefers the resolver to the nameservers for .com.
2. 02 · .comTLD nameserverRefers it to the assigned nameservers for example.com.
3. 03 · CloudflareAuthoritative nameserverAnswers for the requested name. A CNAME may require more lookups.
4. 04 · ResolverAnswer returns to the browserThe resolver caches the answer using its TTL. The web connection follows.

Cloudflare has two roles here that are easy to confuse. Its public resolver, 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:

dig +short NS omaralbeik.com

When I checked on September 17, 2026, it returned:

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 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 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. 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 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 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, 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.

Two ways to arrive at Cloudflare DNS

A new purchase avoids a DNS migration. An existing domain needs its records checked before delegation changes.

1. A · RegistrarBuy a new domain at CloudflareChoose the name and renewal terms, register, and verify email. Cloudflare nameservers are assigned.
2. B · Existing domainKeep an existing registrationCopy records, handle existing DNSSEC, change nameservers at the registrar, and wait for activation.
3. A + BConnect and verify the servicesSet up the website, email, and DNSSEC. Transferring an existing registration remains a separate choice.

What the orange cloud changes

For a site hosted elsewhere, Cloudflare’s proxy setting 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.

After DNS, where does the browser connect?

DNS onlyExternally hosted site

1. Browser
2. →Website server

ProxiedExternally hosted site

1. Browser
2. →Cloudflare
3. →Website server

Worker + Custom DomainApplication on Cloudflare

1. Browser
2. →Cloudflare
3. →Worker

DNS happens before these connections. In the third path, the Worker runs within Cloudflare.

The orange cloud doesn’t mean every response is now cached. Cloudflare’s ordinary CDN doesn’t cache HTML or JSON by default. 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 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 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:

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 also supports comments. Note which service requested the record so you can identify it later.

Reading the Add record form

Illustrative external-server setup. 192.0.2.10 is reserved for documentation and does not host a real website.

1. Type · AThe kind of answerMap a name to IPv4. Use AAAA for an IPv6 address.
2. Name · @The name you are configuringHere, @ means example.com. Entering www means www.example.com.
3. Content · 192.0.2.10The destinationReplace this with the server address supplied by your host.
4. Proxy · Proxied / TTL · AutoTraffic path and cache lifetimeOrange sends web traffic through Cloudflare. TTL governs the DNS answer's lifetime.

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 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. 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 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. DNS is available on the Free plan; 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 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 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. 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 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) 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.

Cloudflare’s standard Universal SSL coverage 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 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 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. 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 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.

Why an old answer can outlive your edit

A simplified DNS-only example with an original one-hour TTL. Times are illustrative.

1. 12:00 · TTL 3600Resolver caches the old answerIt may reuse that address for up to an hour.
2. 12:10 · TTL 300You change the address and lower TTLAuthoritative servers now have the new value. The existing cache gets no push notification.
3. 13:00The original cache lifetime endsOn its next needed lookup, the resolver asks again and gets the new value.

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, 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:

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:

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:

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

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:

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 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 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, 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 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 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.