Cloudflare Command Center: Domains, DNS, Zero Trust, and Tunnels from Beginner to Expert Part 2: Domain Names Explained. Registrars, Nameservers, DNS, and Ownership

Part 1 of this series established why Cloudflare deserves serious attention. It covered what Cloudflare actually is, how it sits between the internet and your infrastructure, and why a 23-part series on a single platform makes sense. If you haven't read it, the concepts in this article will still hold, but the framing will land better with that context in place.

This article doesn't touch a single configuration screen. That's intentional.

Welcome to Part 2: Why Domain Fundamentals Come First

What this series covers and where we are now

Twenty-three parts. That's the full arc of this series, running from the most basic question ("what even is a domain name?") through DNS configuration, Zero Trust architecture, and production-grade tunnel deployments. By the end, you'll have covered the full operational surface of Cloudflare, not just the parts that show up in five-minute YouTube tutorials.

Part 2 sits at the foundation. Everything in this series, from setting up a Cloudflare zone to routing private network traffic through a tunnel, depends on understanding what domain names are, how DNS works, and who controls what. Skip this layer and you'll be copying configuration steps without understanding why they work. That's a fragile position to be in.

Why beginners skip this. And pay for it later

Most tutorials open with "log in to your registrar and update your nameservers." They assume you already know what a registrar is, what nameservers do, and why changing them transfers control. Most people don't know those things. They follow the steps, something breaks six months later, and they have no mental model for diagnosing it.

This article covers domain names, registrars, DNS providers, nameservers, DNS zones, record types, and what domain ownership actually means legally. No configuration. Pure concepts. Read it once and every later part in this series will make more sense.

What Is a Domain Name, Really?

The human-readable layer on top of the internet

Computers communicate using IP addresses. A server doesn't know it as "yourwebsite.com." It knows it as a number, something like 104.21.45.7 for IPv4 or a much longer string for IPv6. Those numbers are precise and machine-friendly, but they're not something humans reliably remember or type without errors.

Domain names exist to solve that problem. They're human-readable labels that map to IP addresses, sitting on top of the underlying numerical addressing system as a translation layer. You type a name, the internet figures out the number, and your browser connects to the right server. The machinery that performs this translation is called the Domain Name System, or DNS.

A useful analogy: a domain name is like a street address on a building. The street address is what you look up in a directory, what you write on an envelope, what you tell someone when they ask where you are. The GPS coordinate is the precise, unambiguous location that navigation systems actually use. The street address is for humans. The coordinate is for machines. DNS is the system that converts one to the other.

Anatomy of a domain: TLD, SLD, and subdomains

Every domain name has a structure. Take "app.yourbrand.com" as an example. Reading right to left: ".com" is the top-level domain (TLD), the category at the top of the naming hierarchy. "yourbrand" is the second-level domain (SLD), the name you actually register and pay for. "app" is a subdomain, a prefix that sits below the registered domain and can point to a completely different service or server.

A single registered domain can serve dozens of different purposes through subdomains. "mail.yourbrand.com" might route to your email server. "api.yourbrand.com" might route to a backend service. "docs.yourbrand.com" might serve a documentation site. All of these share the same registered domain but can point to entirely different infrastructure.

How domain names map to IP addresses

When you type a domain name into a browser, nothing happens instantly. A lookup process runs in the background, consulting a hierarchy of servers to find the IP address associated with that name. That process is DNS resolution, and understanding it is essential before any Cloudflare configuration makes sense. The next few sections break it down step by step.

The Three Roles You Must Not Confuse: Registrar, DNS Provider, and Web Host

Three separate functions keep a domain working. Most people conflate them because many companies offer all three under one roof. That bundling is convenient until something breaks, and then it's a disaster.

What a domain registrar does

A domain registrar is the company you pay to reserve a domain name in the global registry. Registrars are accredited by ICANN, the Internet Corporation for Assigned Names and Numbers, which is the international body that oversees the domain name system's policy and coordination. When you register "yourbrand.com," the registrar records that registration with Verisign (the registry operator for .com domains) and maintains your contact information, renewal dates, and ownership records. GoDaddy, Namecheap, Google Domains, and Cloudflare Registrar are all examples.

The registrar doesn't serve your DNS. It just records that you have the right to use the name.

What a DNS provider does

A DNS provider hosts your DNS zone and answers lookup queries for your domain. When someone's browser asks "what IP address does yourbrand.com point to?", it's the DNS provider's servers that answer. The DNS provider holds your actual DNS records: where your website is, where your email goes, what verification tokens exist for your domain. Cloudflare, AWS Route 53, and Netlify DNS are examples.

Your registrar and your DNS provider don't have to be the same company. Usually, they shouldn't be.

What a web host does

A web host is the server or platform that actually serves your website content when someone reaches it. Vercel, Netlify, a DigitalOcean droplet, an AWS EC2 instance, these are web hosts. The DNS provider tells the internet where to find your web host. The web host delivers the actual files.

Why these three are often bundled. And why that creates problems

GoDaddy will happily sell you a domain, host your DNS, and provide web hosting, all in one account. That feels simple. It's also a single point of failure. If GoDaddy has an outage, or if your account gets compromised, or if you want to move to a better DNS provider, everything is tangled together. Separating the roles gives you flexibility and resilience.

A clean, production-grade setup often looks like this: Cloudflare as registrar, Cloudflare as DNS provider, Vercel or a VPS as web host. Each role is clearly defined, and each can be changed independently without touching the others.

Nameservers: The Delegation System That Makes DNS Work

What nameservers are and what they do

Nameservers are the servers that hold the authoritative DNS records for a domain. When the internet needs to know what IP address "yourbrand.com" points to, it ultimately reaches the nameservers responsible for that domain and asks them directly. Nameservers are the source of truth.

Every domain has at least two nameservers assigned, typically by the DNS provider. Those nameserver addresses are stored at the registrar level, so the global DNS system knows where to route lookup queries for your domain.

Authoritative vs recursive nameservers

Two types of servers participate in every DNS lookup, and they do completely different jobs.

Authoritative nameservers hold the actual DNS records. They have the answers. When queried, they respond with the record values you've configured in your DNS zone.

Recursive resolvers are the intermediaries. Your internet provider, Google (8.8.8.8), or Cloudflare (1.1.1.1) run recursive resolvers. When your browser asks for an IP address, the resolver does the legwork of querying the right servers and returning the answer to you.

The resolution chain works like this. Your browser asks a recursive resolver. The resolver queries a root nameserver (there are 13 root server clusters globally). The root server doesn't know the answer, but it knows which TLD nameserver handles ".com" queries. The TLD nameserver knows which authoritative nameservers are responsible for "yourbrand.com." The resolver queries those authoritative nameservers, gets the actual record, and returns it to your browser.

"Whoever controls the nameservers controls all DNS for that domain. Full stop."

How changing nameservers transfers DNS control

When you add a domain to Cloudflare, the first thing Cloudflare asks you to do is update your nameservers at your registrar to point to Cloudflare's nameservers. That single change transfers DNS authority. From that point forward, Cloudflare's servers are the authoritative source for all DNS queries about your domain.

Changes to nameservers don't take effect instantly. DNS records are cached by resolvers according to a TTL (Time to Live) value, measured in seconds. Until that cache expires, some resolvers will still be pointing to your old nameservers. Full propagation typically takes between a few minutes and 48 hours, depending on TTL values and resolver behavior. Cloudflare usually propagates faster than most, but patience is still required.

DNS Zones: The Container That Holds Your Records

What a DNS zone is

A DNS zone is the administrative container that holds all the DNS records for a domain. Think of it as a configuration file for your domain's presence on the internet. It maps names to values: this hostname points to this IP address, this subdomain aliases to that other domain, this domain's mail should go to these servers.

When you add a domain to Cloudflare, Cloudflare creates a zone for it. Every DNS record you create, modify, or delete lives inside that zone. The zone is what Cloudflare's nameservers read when they answer queries about your domain.

Common DNS record types and what they do

Understanding record types isn't optional. Every configuration task in later parts of this series involves creating or modifying specific record types, and doing it wrong causes real failures.

A records map a hostname to an IPv4 address. This is the most fundamental record type. "yourbrand.com points to 104.21.45.7" is an A record.

AAAA records do the same thing for IPv6 addresses. The format is different but the purpose is identical.

CNAME records create aliases. Instead of pointing a hostname to an IP address, a CNAME points it to another hostname. "www.yourbrand.com is an alias for yourbrand.com" is a CNAME record. CNAMEs cannot be used at the root of a domain in standard DNS, though Cloudflare handles this with a proprietary workaround called CNAME flattening.

MX records direct email. They specify which mail servers should receive email for your domain, and they include a priority value when multiple mail servers exist.

TXT records hold arbitrary text data. They're used for domain verification (proving you own a domain to Google, Microsoft, or other services), SPF records (email sender authorization), and DKIM keys (email signing).

NS records specify which nameservers are authoritative for the domain or a subdomain.

Zone files vs managed DNS dashboards

Historically, DNS zones were managed as raw text files in BIND format, a standard that dates to 1984. Those files are still the underlying format, and understanding them is useful for advanced work. In practice, Cloudflare and every other modern DNS provider expose a dashboard that abstracts the raw file into a table of records you can create and edit without touching the syntax directly.

Domain Ownership: What It Actually Means (and What It Doesn't)

You lease domains, you don't own them

This is the part most people get wrong. You don't own your domain name. You lease it. When you register "yourbrand.com," you're paying for the right to use that name for a defined period, typically one to ten years. When that period ends and you don't renew, the right to use the name lapses. Someone else can register it. Your website goes dark, your email stops working, and anything tied to that domain breaks.

The distinction matters practically. It means domain renewals are not optional maintenance. They're the mechanism by which you retain control of your entire online presence.

WHOIS, ICANN, and the registry layer

ICANN sets the global policy framework for domain names. Below ICANN sit registries, the operators of specific TLDs. Verisign operates .com and .net. The Public Interest Registry operates .org. Each registry maintains the authoritative database of registered names within their TLD.

Registrars sit below registries. When you register a domain through Namecheap or Cloudflare Registrar, the registrar submits the registration to the appropriate registry on your behalf.

WHOIS is the public database that records who registered a domain, when it was registered, when it expires, and what nameservers it uses. Historically, registrant contact information was fully public. Most registrars now offer WHOIS privacy protection, which substitutes the registrar's proxy contact details for your personal information. Use it. Exposed registrant contact information is a social engineering target, and it's used in domain hijacking attempts.

What happens when registration lapses

The domain lifecycle runs through several stages. After the registration period ends, there's a grace period (typically 30 days) during which you can renew without penalty. After that comes a redemption period (typically 30 more days) during which renewal is possible but expensive, often $100 or more in redemption fees. After redemption, the domain enters a pending delete phase and then becomes available for anyone to register.

The practical consequence of expiration is total.

The Domain Lifecycle: From Purchase to Transfer

Buying a New Domain: What Actually Happens

You search for a domain name, find one that's available, and pay for it. That part feels simple. What happens underneath is a bit more involved, and understanding it will save you confusion later.

When you search for availability, your registrar queries the registry for that TLD. If the name is unregistered, you can claim it. You pay the registrar, the registrar submits a registration to the registry, and within minutes your domain exists in the global DNS system. The registry updates its authoritative records, and the domain is officially tied to your registrar account. At that point, you control the nameserver settings, the WHOIS contact information, and the renewal cycle.

Transferring an Existing Domain to a New Registrar

Moving a domain from one registrar to another requires an EPP code, also called an auth code or transfer authorization code. This is a unique string your current registrar generates. It proves you're authorized to initiate the transfer. Without it, the receiving registrar can't complete the move.

The transfer process follows a consistent sequence. First, unlock the domain at your current registrar. Most registrars apply a registrar lock by default, which blocks outgoing transfers. You disable it temporarily. Then you request the EPP code, usually delivered to the registrant contact email. You initiate the transfer at the new registrar, enter the auth code, and confirm. The old registrar gets a notification and has a window to approve or object. If nothing is contested, the transfer completes in five to seven days, after which your domain lives at the new registrar.

Take a concrete example. A business running on GoDaddy decides to move to Cloudflare Registrar. They unlock the domain in GoDaddy's control panel, request the auth code, log into Cloudflare, start the transfer, paste the code, and confirm via email. A week later, the domain is registered through Cloudflare at wholesale cost, with automatic DNSSEC and integrated DNS management. No upsells, no inflated renewal pricing.

One thing to be clear about: transferring your registrar does not automatically change your DNS provider. These are separate systems. You can move your domain to Cloudflare Registrar and still have your DNS zone hosted at your old provider. Changing nameservers is a separate step, and Part 3 covers exactly that.

The 60-Day Transfer Lock Rule

ICANN imposes a 60-day lock on domain transfers after two specific events: a new registration and a completed transfer. If you just registered a domain, you can't transfer it to another registrar for 60 days. If you just completed a transfer, the same rule applies. This exists to prevent fraud and unauthorized domain movement.

Plan around this rule. If you're consolidating domains to Cloudflare Registrar and one was recently registered or transferred, you'll need to wait out the lock period before initiating the move. There's no workaround.

Why Bad Registrar Practices Create Serious Risk

Registrar Lock and Why You Should Always Enable It

Registrar lock, sometimes called transfer lock or domain lock, is a flag you set at the registrar level that prevents any outgoing transfer from being initiated. When it's on, even someone with your EPP code can't move the domain. They'd need to log into your registrar account and disable the lock first. That's an extra layer of friction that stops a large category of attacks cold.

Enable it on every production domain. Check it quarterly. Treat it like a seatbelt: it's not there because you expect a crash, it's there because crashes happen without warning.

Account Security Failures at the Registrar Level

Most domain hijackings don't involve sophisticated exploits. They involve someone logging into a registrar account with credentials that were weak, reused, or compromised in a breach.

If your registrar account has no MFA, a determined attacker who gets your password owns your domain. That's it. From inside the registrar account, they can change nameservers, disable registrar lock, request an EPP code, and initiate a transfer. The whole chain takes minutes.

The registrar contact email creates another exposure point. If the email address tied to your registrar account is compromised, password reset flows hand over full account access. Your domain security is only as strong as the security of that inbox.

Shared credentials make this worse. Teams that share a single registrar login with no MFA, no audit log, and no individual accountability are one phishing email away from losing a domain they've held for a decade.

Domain Hijacking: How It Happens and Who It Happens to

Domain hijacking is not a theoretical risk. It's a documented, recurring attack pattern that hits businesses of every size. The attacker gains access to the registrar account, changes the nameservers to infrastructure they control, and redirects traffic. Email stops arriving at your servers. SSL certificates fail validation. Your website serves whatever the attacker wants.

"We didn't know the domain had been hijacked until customers started calling to report our website was showing a pharmaceutical ad."

That's not a hypothetical quote. It's the kind of incident report that shows up in security post-mortems regularly. Recovery can take days. The reputational damage lasts longer.

The Danger of Letting Domains Expire Accidentally

Auto-renewal failures are more common than most people expect. A credit card expires. The registrar sends renewal notices to an email address nobody checks. The domain lapses. Within hours, domain squatters with automated tools can register it.

Getting an expired domain back, if it's even possible, is expensive and slow. Some TLD registries hold expired domains in a redemption period with steep recovery fees. Others release them immediately to the open market.

Confirm auto-renewal is active. Keep payment methods current. Set calendar reminders for domains that are close to expiration. This is unglamorous work, but it's the kind of thing that prevents a catastrophic Monday morning.

Access Control and Why Domain Ownership Is a Security Problem

Who in Your Organization Should Have Registrar Access

Most organizations treat DNS and registrar access as an afterthought. It gets handed to whoever set it up originally, usually a developer or IT generalist, and then it lives in that person's personal account for years. Nobody documents it. Nobody audits it. Nobody thinks about it until something breaks.

That approach doesn't hold up. DNS changes are among the highest-impact actions anyone can take on your infrastructure. Changing a nameserver record redirects all traffic for your domain. Changing an MX record breaks email. Changing an A record can take down a production service in minutes.

The question of who has registrar access is a security question, not an administrative one.

The Principle of Least Privilege Applied to DNS

Least privilege means giving people exactly the access they need to do their job, and nothing more. Applied to DNS: a developer who needs to verify a domain for a third-party service doesn't need the ability to change nameservers. A contractor setting up a subdomain doesn't need access to your registrar account at all.

The problem with most registrar setups is that access is binary. You either have the login or you don't. That's why moving DNS management to a platform with proper role separation matters.

Cloudflare's Account Roles and How They Help

Cloudflare accounts support multiple users with distinct roles. Administrators have full access. Other roles restrict what users can view or modify. Someone can have read-only access to DNS records without the ability to change nameservers or touch registrar settings.

This is how DNS access should be structured. Not everyone who needs visibility needs write access. Not everyone who manages DNS records needs access to billing or account settings. Future parts of this series cover Cloudflare account setup and team access in detail, but the principle is worth establishing now: treat DNS access like access to a production system, because that's exactly what it is.

Where Cloudflare Fits Into This Picture

Cloudflare as DNS Provider: The Most Common Entry Point

Most people encounter Cloudflare the same way. They have a domain registered somewhere, they've heard Cloudflare is fast and adds some protection, and they change their nameservers to point at Cloudflare's DNS infrastructure. That's it. The domain stays at the original registrar. The DNS zone moves to Cloudflare.

This works well and it's the most common configuration. Cloudflare becomes the authoritative DNS provider for your domain, meaning all DNS queries for your zone get answered by Cloudflare's servers. Your registrar is still collecting the renewal fee and holding the registration record. The two roles are separate.

Cloudflare as Registrar: At-Cost Domains With Built-In Security

Cloudflare Registrar is a different product. Instead of just managing your DNS zone, Cloudflare holds the domain registration itself. The pricing model is straightforward: you pay the registry's wholesale cost. No markup, no renewal price hikes after the first year, no upsells for privacy protection that should be free anyway.

When Cloudflare is both your registrar and your DNS provider, the setup simplifies considerably. Nameserver configuration is automatic. DNSSEC is enabled by default without manual key management. Your domain, your DNS zone, and your security settings all live in the same dashboard.

Why Using Cloudflare for Both Simplifies Everything

Cloudflare runs one of the largest anycast networks in the world. When a DNS query comes in for your domain, it gets answered by the nearest Cloudflare node in a global network spanning hundreds of cities. That's why Cloudflare's DNS is consistently among the fastest resolving in independent benchmarks. It's not magic. It's geographic distribution at scale.

One thing Cloudflare is not: a traditional web host. You can't upload a PHP application and have Cloudflare run it. Cloudflare can serve static sites through Cloudflare Pages, and it can proxy traffic to your origin server, but the origin server itself lives elsewhere. That distinction matters when you're planning your infrastructure, and it'll come up again in later parts of this series.

Part 3 walks through adding a domain to Cloudflare, reviewing the DNS records that get imported automatically, and making your first live nameserver change.

Your Domain Foundation Checklist

Before You Configure Anything in Cloudflare, Verify These Fundamentals

Before you change a single nameserver or touch a DNS record, run through this checklist. These aren't optional steps. They're the baseline that makes everything else safe to do.

What's Next: Putting These Concepts Into Practice

A Preview of Part 3

Part 1 introduced the series and the Cloudflare ecosystem at a high level. This part covered the conceptual layer that makes all the configuration work meaningful: what domain names actually are, how registrars and DNS providers differ, what nameservers do, how DNS zones are structured, and why ownership and access control are security problems worth taking seriously.

None of that was configuration. It was foundation. And foundation is what makes the difference between someone who follows instructions and someone who understands what they're doing when something goes wrong.

Part 3 gets hands-on. You'll add a domain to Cloudflare, walk through the DNS records that get imported automatically, and make your first live nameserver change. That's the moment the concepts in this article become real. Before you get there, complete the checklist above.

Key Terms to Remember From This Article

A quick reference for the vocabulary this article introduced: Registrar is the company where you register and renew your domain. DNS provider is the service that hosts your DNS zone and answers queries. Nameserver is the server address that tells the internet where to find your DNS zone. DNS zone is the complete set of records for your domain. A record maps a hostname to an IPv4 address. CNAME maps a hostname to another hostname. TTL controls how long resolvers cache a DNS record before checking again. EPP code is the transfer authorization code required to move a domain between registrars. Registrar lock is the flag that prevents unauthorized outgoing transfers.

These terms will appear throughout every remaining part of this series. If something in Part 3 feels unclear, this glossary is the first place to look.