The DNS root is the unnamed zone at the top of the hierarchy. A top-level domain is the last label — .com, .org, .uk. What most people mean by root domain is the apex: example.com without a subdomain, which is the thing you actually configure.
Three different concepts share overlapping names, and the overlap causes real confusion in practice — particularly when someone reads that you cannot put a CNAME at the root and is not sure which root is meant. Sorting the hierarchy out takes two minutes and makes several DNS restrictions stop looking arbitrary.
Table of contents
- The hierarchy, from the top
- The apex restriction that trips everyone up
- Apex or www: pick one and redirect the other
- How a lookup actually walks the hierarchy
- How this fits the rest of the stack
- FAQ
The hierarchy, from the top
A fully qualified domain name is a series of labels separated by dots, read right to left, ending in an invisible dot for the root.
blog.example.com.
| | | |
| | | +-- the root (an empty label, usually not typed)
| | +------ top-level domain (TLD)
| +-------------- second-level domain
+------------------- subdomain (third level)- The root zone is the top of the hierarchy. It has no name — its label is empty, which is the trailing dot. It is served by the root nameservers and contains delegations to every TLD.
- The top-level domain is the rightmost named label:
.com,.org,.uk,.io. TLDs are listed in the root zone database maintained by IANA, and each has an operator who runs its nameservers. - The second-level domain is what you register: the
exampleinexample.com. - Subdomains are anything to the left:
blog,www,api.
So .com is a top-level domain and example.com is a registered domain at the second level. Strictly, neither is the root — the root is the empty zone above all of them.
In everyday use, root domain almost always means example.com as opposed to blog.example.com. The precise term for that is the apex, sometimes called the zone apex or naked domain, and it is the term worth adopting because it is unambiguous.
The apex restriction that trips everyone up
You cannot put a CNAME record at the apex. Not a policy choice — a consequence of how DNS is specified.
A CNAME says this name is an alias for that name, and the specification requires that a name with a CNAME have no other records. The apex must have NS records, and needs SOA and usually MX. So a CNAME at the apex would conflict with records that are mandatory.
# Illegal -- the apex already has NS and SOA
example.com. CNAME myapp.hosting.com.
# Fine -- a subdomain can be an alias
www.example.com. CNAME myapp.hosting.com.This is why platforms ask for an A record at the apex and a CNAME for www, and why pointing an apex at a service that only publishes a hostname is awkward — the address behind that hostname can change, and a hardcoded A record will not follow it.
Three workarounds exist, in descending order of quality:
- ALIAS or ANAME records. A provider-specific record type that behaves like a CNAME at the apex by resolving the target and answering with its addresses. Not a DNS standard, so support varies by provider. This is the right answer where available.
- A redirect from apex to www. Serve a permanent redirect at the apex and host the site on
www. Simple, and it costs a redirect hop on the first request. - A static A record. Only where the target address is genuinely stable, which for most managed platforms it is not.
Related, and worth knowing: _dmarc, _domainkey and ACME validation records all live at subdomains, so they are unaffected by the apex restriction.
Apex or www: pick one and redirect the other
Serving the same content at both example.com and www.example.com without a redirect is a genuine problem rather than a stylistic one.
- Duplicate content. Search engines see two URLs for every page and have to guess which is canonical, splitting whatever ranking signals point at each.
- Split analytics. Sessions crossing between the two look like separate visits.
- Cookie scope. A cookie set at the apex is sent to every subdomain, including any you did not intend — a staging subdomain, a third-party-hosted status page.
- Certificate coverage. Both hostnames must be on the certificate, or one of them errors.
Pick one as canonical, redirect the other with a 301, and set a canonical link tag. Which one you pick matters less than picking.
Arguments for www: it can be a CNAME, so it moves cleanly between hosts, and it keeps cookies off the apex and therefore off your subdomains. Arguments for the apex: it is shorter, and it is what people type.
For a project that will grow subdomains — an API, a docs site, a dashboard — the cookie-scoping argument for www is the strongest technical one. For a marketing site that will never have subdomains, the apex is fine.
Check what you are currently serving:
curl -sI https://example.com | head -n 3
curl -sI https://www.example.com | head -n 3
dig example.com A +short
dig www.example.com CNAME +shortHow a lookup actually walks the hierarchy
Understanding the resolution path explains why propagation behaves the way it does.
- Your resolver asks a root nameserver about
blog.example.com. The root does not know, but it knows who runs.com, and returns that referral. - The resolver asks a
.comnameserver. It does not know the answer either, but it knows which nameservers are authoritative forexample.com— that is the delegation created when you set nameservers at your registrar. - The resolver asks those nameservers, which hold your zone and return the actual record.
- The resolver caches the answer for its TTL and serves it to you.
Two useful consequences. Changing nameservers at your registrar changes step two, which is why it is slower to take effect than changing a record inside your zone — you are updating a delegation held by the TLD operator, with its own TTL. And changing a record inside your zone only affects step three, which is why lowering a record’s TTL in advance genuinely helps.
Watch the whole path when something is not resolving:
dig +trace blog.example.comThat walks from the root down and shows exactly where the chain breaks, which is far more informative than a single query returning nothing.
How this fits the rest of the stack
Most DNS confusion comes from the vocabulary rather than the protocol. Once the hierarchy is clear, the apex CNAME restriction stops being a mysterious rule and becomes an obvious consequence, and the apex-versus-www decision becomes a choice with reasons rather than a coin flip.
On the hosting side, the apex problem is usually solved for you. RunxBuild handles custom domains on static sites and web services with certificates issued and renewed automatically, and redirects and response headers configured in the dashboard rather than in a server file — so an apex-to-www redirect is a setting, not a config you maintain. Static sites include 120GB of bandwidth, then $0.10/GB. Services in Node, Next.js, Python, Go, Ruby, Java, .NET or Docker deploy from your GitHub repository, with managed MySQL and Postgres behind them on private networking. To see what a site, a service and a database come to, the RunxBuild hosting calculator lists them as separate line items.
Useful related references:
- What Is a Top-Level Domain? The Part After the Last Dot
- What Is a .link Domain, and When Does It Fit a Project?
- Domain Squatting: What It Is, What You Can Do, and What Is Not Worth Doing
- Custom domains and certificates on RunxBuild
FAQ
What is the difference between a root domain and a top-level domain?
A top-level domain is the last label — .com, .org, .uk — and is delegated from the DNS root zone. The DNS root itself is the unnamed zone above every TLD, represented by the trailing dot. What people usually call a root domain is really the apex: example.com with no subdomain.
Why can I not create a CNAME record at the apex?
Because the DNS specification says a name with a CNAME can have no other records, and the apex must carry NS and SOA records. Providers work around it with ALIAS or ANAME record types, which resolve the target and answer with its addresses — non-standard, but the cleanest solution where supported.
Should my site use www or the apex?
Pick one, redirect the other with a 301, and set a canonical link tag. www can be a CNAME, so it moves between hosts cleanly, and it keeps cookies off the apex and therefore off your other subdomains. The apex is shorter and is what people type. For anything that will grow subdomains, www has the stronger technical case.
What is an apex domain?
The domain at the top of your zone with no subdomain in front of it — example.com rather than www.example.com. It is also called the zone apex, root domain or naked domain. The apex is where NS and SOA records live, which is why it has restrictions subdomains do not.
Why do nameserver changes take longer than record changes?
Because they change a delegation held by the TLD operator, one level up the hierarchy, with its own TTL. Changing a record inside your zone only affects the answer your own nameservers give, which is why lowering that record’s TTL in advance shortens the wait and does nothing for a nameserver change.