ClouDNS — CNAME flattening

A Webflow site on a custom domain needs its root to answer with an address. The root of a DNS zone is not an ordinary hostname: it already carries the SOA and NS records that make the zone authoritative, and a CNAME cannot share a name with other records. That single constraint is why pointing a bare domain at a hosted platform is harder than pointing www at it.

CNAME flattening is the workaround DNS hosts built for that constraint. ClouDNS implements it as an ALIAS record: you store a hostname at the root, ClouDNS resolves that hostname on its own servers, and it answers queries with plain A and AAAA records. The root behaves like a CNAME without holding one.

The question this page answers is whether you should use it for Webflow. Webflow documents a static A record at the apex and says an alternative setup is no longer needed, and ClouDNS documents its own reasons not to point an ALIAS at a CDN. Both facts matter before you change a zone that is already serving a client.

How to integrate ClouDNS CNAME flattening with Webflow

What is ClouDNS CNAME flattening? It is the behaviour of the ClouDNS ALIAS record, which resolves a CNAME-style target at the zone apex and returns the resulting addresses as A and AAAA records. ClouDNS has run managed DNS since 2010 across 65 data centers in 33 countries, and ALIAS is available through both the control panel and the HTTP API.

Start from the decision rather than the click path. The general work of pointing a ClouDNS-hosted domain at Webflow, creating the zone, adding the www CNAME and the verification TXT record, is covered on the ClouDNS integration page. What follows is specific to the apex: why the constraint exists, what flattening changes, and what it costs you.

The apex constraint explains why a CNAME cannot live at the root of a zone and what flattening substitutes for it. The apex decision then weighs a ClouDNS ALIAS record against the A record Webflow documents, including the limitation ClouDNS publishes about CDN targets. Read both before changing a live zone. The provisioning path that follows, by hand and through the ClouDNS HTTP API, assumes you have already decided.

Why a CNAME cannot sit at the zone apex

The restriction is in the DNS specifications, not in Webflow or ClouDNS. RFC 1034 describes the records at the top node of a zone as two kinds: name server records listing every server for the zone, and a single SOA record holding the zone management parameters. Those records have to be there for the zone to answer at all.

RFC 1912 then rules out sharing that name. It states that a CNAME record "is not allowed to coexist with any other data", and the example it uses to illustrate the mistake is a zone apex carrying NS records and a CNAME together. So example.com can hold an A record, or MX records, or a CNAME, but not a CNAME alongside anything else, and the SOA and NS records are not optional.

Flattening resolves the conflict by moving the indirection off the wire. ClouDNS stores the target hostname, follows it from its own nameservers, and publishes the resulting addresses as A and AAAA records at the root. A resolver querying example.com never sees a CNAME, so nothing in the specification is violated. The cost is that the lookup now happens at ClouDNS, on ClouDNS timing, from ClouDNS locations, which is where the limitations below come from.

Choose between the apex A record and a ClouDNS ALIAS

Webflow documents the A record, and for most sites that ends the discussion. The manual connection guide lists an A record on host @ with the value 198.202.211.1, a CNAME on www pointing at cdn.webflow.com, and a TXT record on _webflow carrying the one-time-verification= string from Site settings. Webflow also states directly that an alternative DNS setup is no longer needed to serve a site at the bare domain, so flattening buys nothing on the question it was historically used to solve.

ClouDNS publishes a limitation that lands on this exact configuration. The ALIAS article warns that "it's not recommended to point an ALIAS record to a GeoDNS record/CDN service, as it may not function as intended", and a section of the same article is headed Incompatibility with GeoDNS and CDN Services. cdn.webflow.com is a CDN hostname, so this is not a hypothetical edge case, it is the documented shape of the setup.

Read that warning accurately rather than at maximum volume. It describes ALIAS resolution returning an edge address chosen for the DNS host location instead of the visitor location. Queried from five public resolvers on separate networks, cdn.webflow.com currently returns one address everywhere, and it is the same address Webflow documents for the apex, so there is no per-location answer to get wrong today. That is a property of the current infrastructure, not a guarantee, and it is checkable in a few seconds with dig.

Weigh the two paths on what actually differs:

• What breaks on change: An A record holds a literal address and needs editing if Webflow renumbers, which it did in the migration that blocked publishing to legacy records from January 13, 2026. An ALIAS follows the hostname instead.
• What Webflow supports: Only the A record appears in Webflow's own DNS instructions, so an ALIAS at the apex is a configuration you are choosing to run outside the documented path.
• What ClouDNS restricts: An ALIAS cannot coexist with a CNAME or a Web Redirect record, so a zone using ClouDNS redirects at the root has to give one of them up.
• What the answer contains: ALIAS returns AAAA records as well as A records, so a flattened root starts answering over IPv6 with an address Webflow does not document for the apex.

Use the A record unless you have a specific reason not to pin an address, and treat an apex ALIAS as something you test from several regions before a client's domain depends on it.

Add a flattened apex record in the ClouDNS control panel

A paid Webflow Site plan comes first: the free Starter plan publishes to a .webflow.io subdomain only, and a custom domain needs an upgrade. Assuming the zone already exists and www already points at cdn.webflow.com, the apex change is four fields and one deletion.

To flatten the root:

1. Open the zone management page and delete any existing A record on the root host, because Webflow treats an extra root A record as a conflict and ClouDNS will otherwise answer with both.
2. Click Add new record and set Type to ALIAS.
3. Leave the Host field blank so the record applies to the root.
4. Enter cdn.webflow.com in the Points to field.
5. Leave TTL at 3600 and save.

That TTL is not a preference on a Free account. The ClouDNS TTL article states the default is 3600 seconds and that the 60 to 2,592,000 second range is available only to Premium, DDoS Protected and GeoDNS subscriptions, so a free zone cannot shorten the window before a migration.

Before deleting anything, read the current values in Site settings > Publishing > Production. Sites created before April 21, 2025 can legitimately require two A records, and Webflow says to add both, so a blanket instruction to delete every other root A record is wrong on those sites. Once the record resolves, confirm the domain from the same panel, then publish.

If the domain reports an error afterwards, the domain error guide covers the usual causes: a second A or CNAME record on the same host, legacy record values, and CAA records that do not permit Webflow's certificate authorities. If your zone holds CAA records, the CAA guide asks for both 0 issue "letsencrypt.org" and 0 issue "pki.goog; cansignhttpexchanges=yes". Certificates then renew automatically, which is why the ClouDNS Free SSL feature is irrelevant to a Webflow site. Propagation can take up to 48 hours, though it usually finishes within a few hours.

Provision flattened apex records through the ClouDNS API

The HTTP API matters here for one reason: it is how you apply the same apex decision to fifty client zones without opening fifty control panels. API access is not on the free tier. ClouDNS states that its Premium DNS and DDoS Protected DNS plans include HTTP API access, in the setup article where that requirement is spelled out. Every call carries auth-id and auth-password, or sub-user credentials, and endpoints accept GET or POST with .json or .xml appended.

To create a flattened apex record:

1. Register the zone if it does not exist, with POST https://api.cloudns.net/dns/register.json and domain-name=example.com plus zone-type=master (Register zone).
2. Add the apex record with POST https://api.cloudns.net/dns/add-record.json, record-type=ALIAS, an empty host, record=cdn.webflow.com and ttl=3600. Send record-type=A with record=198.202.211.1 instead for the documented setup.
3. Confirm the zone is served with POST https://api.cloudns.net/dns/is-updated.json and domain-name=example.com.
4. Read the zone back with POST https://api.cloudns.net/dns/records.json, filtering on host and type, to check that exactly one record answers at the root (List records).

Watch the parameter name on step 2. The Add record article names the field type in its parameter table and record-type in every one of its worked examples. The examples are what most integrations are built from, so send record-type and log the response rather than assuming either name is safe.

Handing a client their own scoped login uses a different endpoint, and its parameters are easy to get wrong. POST https://api.cloudns.net/sub-users/add.json requires password, zones and mail-forwards, and the access level is set with write, where 0 is read and 1 is read and write (Add sub-user). There is no access-level parameter on that call.

On the Webflow side, publishing is scriptable but connecting a domain is not. Webflow's Data API reference documents custom domains as readable with the sites:read scope, and no endpoint for adding one, so the domain has to be attached in Site settings first. After that, POST https://api.webflow.com/v2/sites/{site_id}/publish with {"customDomains": ["<domain_id>"]} and the sites:write scope returns 202 on acceptance (Publish Site). Requests authenticate with an Authorization bearer token.

To catch a zone that has drifted, register a site_publish webhook and re-read the records when it fires. The event payload carries siteId, publishedOn and domains, and arrives with an x-webflow-signature header that Webflow documents as a SHA-256 HMAC hash, so validate it before acting. ClouDNS has no equivalent record-change event: its outbound webhook notifications open a URL when a monitoring check flips between UP and DOWN, which tells you the root stopped answering but not that somebody edited it.

What you can build with ClouDNS CNAME flattening and Webflow

Flattening earns its place in a handful of specific situations, all of them about the apex rather than about Webflow hosting generally.

The setups where an apex ALIAS is worth the tradeoff include:

• Client root domain with live mail: An ALIAS coexists with MX and TXT records, so a freelancer can serve the marketing site from the bare domain while the client's mailboxes and SPF records stay untouched in the same zone.
• Zones you do not want to renumber: An agency holding many client zones can point every root at a hostname instead of a literal address, so a future Webflow address change is absorbed by resolution rather than by fifty edits.
• Scripted apex provisioning: A single add-record call with record-type=ALIAS and an empty host creates the root record, so zone setup for a new client site fits inside the same script that registers the zone and adds the verification TXT record.
• Drift detection on the root: A site_publish webhook plus a records read gives you a check that runs on every publish and tells you whether the apex still holds one record with the value you expect.

Each of these still carries the CDN caveat ClouDNS publishes, so resolve the root from several regions after any change. If the API half of this is new to you, start with applying custom code through the Webflow Data API to get the authentication and scope model straight first.