ControlPlane Labs

Two RFC Discrepancies in Cloudflare's DNS Docs

by ControlPlane Labs 5 min read
dns documentation infrastructure

Cloudflare’s Learning Center is one of the most widely referenced resources for understanding DNS fundamentals. It is well-written, accessible, and often the first result when people search for DNS concepts. This post provides technical clarifications on a few points where the documentation differs from the behavior specified in the relevant RFCs.

The following observations are based on Cloudflare’s DNS educational content. (Quotes captured February 2026.)

1. CNAMEs Cannot Be Used at the Apex Domain#

What Cloudflare says:

“A CNAME record is used in lieu of an A record, when a domain or subdomain is an alias of another domain.”

Clarification:

The phrasing “a domain or subdomain” may suggest that a CNAME can be used for either. Per the DNS RFCs, a CNAME record cannot exist at the zone apex (the root domain like example.com), only on subdomains.

The technical reason:

RFC 1034 §3.6.2 states:

“If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.”

RFC 1912 §2.4 reinforces this (even more explicitly):

“A CNAME record is not allowed to coexist with any other data.”

Apex domains must have SOA and NS records to function as a valid DNS zone (RFC 1034 §4.2.1). This creates an irreconcilable conflict (compliant DNS software will reject a CNAME at the apex).

What works:

  • www.example.com CNAME example.com (valid)
  • blog.example.com CNAME hosting.provider.com (valid)
  • example.com CNAME other-domain.com (invalid)

Provider-specific alternatives:

Some DNS providers offer proprietary solutions that behave like CNAMEs at the apex (but technically are not standard CNAME records):

  • Cloudflare: CNAME flattening; resolves any target hostname to an IP and returns an A record. Works with any external target.
  • AWS Route 53: ALIAS records; resolves the target to an IP and returns an A record, but only for AWS resources (CloudFront distributions, ELB/ALB/NLB, S3 website endpoints, API Gateway, Elastic Beanstalk, etc.). Route 53 will not create an ALIAS record pointing to a non-AWS hostname. This makes Route 53 ALIAS significantly more restrictive than Cloudflare’s CNAME flattening or DNSimple’s ANAME.
  • DNSimple: ANAME records; resolves any target hostname to an IP and returns an A record. Works with any external target.

These resolve the CNAME target to an IP address at the DNS provider level and return an A record to the client (sidestepping the RFC restriction). However, Route 53’s implementation is limited to AWS-hosted targets; if your apex domain needs to resolve to a non-AWS resource, Route 53 ALIAS won’t work.

Cloudflare’s CNAME article does include a “restrictions” section that mentions CNAMEs cannot coexist with other record types (including SOA). The connection to apex domain restrictions is implicit rather than explicit.

2. Subdomains Do Not Require “Additional Nameservers”#

What Cloudflare says:

“It’s worth mentioning that in instances where the query is for a subdomain such as foo.example.com or blog.cloudflare.com, an additional nameserver will be added to the sequence after the authoritative nameserver, which is responsible for storing the subdomain’s CNAME record.”

This statement appears in the section explaining what an authoritative nameserver is.

Clarification:

  1. The authoritative nameserver is the final stop in the resolution chain. There is no additional nameserver “after” it in the standard resolution process.

  2. Subdomains do not automatically have CNAME records. A subdomain can have any record type (A, AAAA, MX, TXT, etc.).

  3. The authoritative nameserver handles subdomains directly. Per RFC 1034 §4.2.1, a zone’s authoritative data includes all records “from the top node of the zone down to leaf nodes or nodes above cuts.” The nameserver for example.com is authoritative for foo.example.com (unless explicitly delegated).

How subdomain resolution actually works:

  1. Resolver asks root nameserver about .com
  2. Root returns TLD nameservers for .com
  3. Resolver asks TLD nameserver about example.com
  4. TLD returns authoritative nameservers for example.com
  5. Resolver asks authoritative nameserver about foo.example.com
  6. Same authoritative nameserver returns the record

The authoritative server handles the subdomain directly (no additional nameserver is involved).

When additional lookups actually happen:

  • Explicit delegation: The parent zone delegates a subdomain to different nameservers via NS records (e.g., api.example.com hosted by a different provider). This requires explicit configuration.
  • CNAME chasing: If foo.example.com returns a CNAME pointing to bar.otherdomain.com, the resolver starts a new, independent lookup for otherdomain.com. This is a separate resolution chain (not “an additional nameserver after the authoritative nameserver”).

Summary#

Claim Reality RFC Reference
CNAMEs work for “a domain or subdomain” CNAMEs only work for subdomains (apex domains cannot have CNAME records) RFC 1034 §3.6.2, RFC 1912 §2.4
Subdomains add “an additional nameserver after the authoritative nameserver” The authoritative nameserver handles subdomains directly (no additional nameserver is involved). Subdomains can have any record type, not just CNAMEs. RFC 1034 §4.2.1

References#

RFCs:

  • RFC 1034 - Domain Names - Concepts and Facilities (November 1987)
  • RFC 1912 - Common DNS Operational and Configuration Errors (February 1996)

Cloudflare Learning Center articles referenced:

This review only covered two articles from the Learning Center. If you spot other discrepancies between Cloudflare’s documentation and the RFCs, feel free to reach out.

Related posts