Cloudflare's New DNS Editor: A Beginner's Plan for Connecting an App Domain

Your AI-built app works at the hosting company's preview address. Now you want it at your own domain. The assistant tells you to change a DNS record, and the dashboard shows a successful save.

Is the app live?

Not necessarily. You have changed one part of the route a visitor takes. You still need to prove that the intended hostname reaches the intended application, over a working secure connection, with the behavior you actually built.

This article was prepared with AI assistance. The examples are proposed checks for a hypothetical app, not a report of a production migration I performed.

On October 30, 2026, Cloudflare retired its classic DNS records page. Its newer editor is now the default across all plans. The update also confirms that you can change an existing record's type, such as from A to CNAME, directly in the dashboard.

That is a useful interface improvement. It is also a good reason to stop following old screenshots without understanding what their fields mean.

My rule for a beginner is simple: explain the intended hostname change in plain language before asking AI to make it.

Start with one hostname, not the whole domain

Imagine a small appointment app. Your marketing site lives at www.example.com, the app will live at app.example.com, and email already works for the business. These are illustrative names, not configuration values to copy.

The requested change is to connect the app hostname. It is not permission to replace the marketing site, change nameservers, delete unfamiliar records, or alter email delivery.

I would write this first:

"Only app.example.com should change. It should reach the deployment identified by our hosting provider. The marketing site and email records must remain unchanged."

That one sentence makes an assistant's proposed diff much easier to judge. A suggestion to rewrite every record is now visibly outside the job.

If you need help turning a vague build request into explicit boundaries, my $3 AI App Builder Starter Prompts provide a guided starting point. You can also use the change note below on its own.

Read the record as a statement

Cloudflare's record-type reference distinguishes an A record, which maps a name to an IPv4 address, from an AAAA record for an IPv6 address and a CNAME record that points to another hostname.

Those are different meanings, not three interchangeable ways to paste a website URL. A DNS target is not an HTTPS URL with a path such as /dashboard.

Use the exact record type and destination supplied by your host for that project. Do not ask AI to infer the destination from a company name, an old tutorial, or another project's configuration.

Before changing anything, record the current name, type, value, proxy status, and TTL. Note whether the hostname already has other records and ask the provider's documentation what combinations are supported. Save enough information to restore the specific previous configuration without exposing account secrets.

Changing the record's type may be one click in the new editor. It still changes what the record says.

Decide whether traffic should pass through a proxy

The orange cloud is not a generic indicator that a domain is configured correctly.

Cloudflare's proxy-status documentation explains that a proxied record routes HTTP/HTTPS traffic through Cloudflare. A DNS-only record directs it to the origin without that HTTP proxy path. Only A, AAAA, and CNAME records can be proxied; MX and TXT records are DNS-only.

The important beginner question is therefore not "Which icon looks enabled?" It is "Which traffic path does this service support and require?"

A website hostname and a record used to prove ownership can need different treatment. Follow the hosting or verification provider's instructions for each purpose. Do not change proxy status merely to make an error disappear, particularly if doing so would remove protections you depend on.

For the hypothetical appointment app, write down the expected path before the change: visitor, optional proxy, hosting project, application. If you cannot name the hosting project, you are not ready to change the destination.

Keep a short change note

Here is the note I would give an AI coding assistant before authorizing a production edit:

1. Scope: the exact hostname being changed and the services that must remain untouched.
2. Before: the current record and the evidence that it belongs to this hostname.
3. After: the proposed record, supported by this project's hosting instructions.
4. Traffic path: whether the record is proxied and why that choice is supported.
5. Checks: what will establish correct DNS, a working secure connection, and the intended app behavior separately.
6. Recovery: the specific previous values, who can restore them, and the failure that would trigger restoration.

Ask the assistant to identify unknowns rather than completing this note with plausible guesses. A blank destination is safer than the wrong destination presented confidently.

This is intentionally small. You do not need a migration dashboard for a first app. You do need a record of what you meant to change.

A saved record is only the first receipt

After the change, collect three different kinds of evidence.

First, inspect the DNS answer for the exact hostname and compare it with the expected behavior. For a proxied hostname, seeing Cloudflare's addresses can be correct; looking only for your origin IP would be the wrong test.

Second, open the intended HTTPS address and confirm that it reaches the right application without a certificate warning. Do not bypass a browser warning to declare the launch successful.

Third, perform a harmless representative workflow with test data. For our appointment example, that might be opening the booking page and verifying its available-time display. Do not create real bookings, send customer messages, or trigger charges just to make a checklist look complete.

A successful DNS lookup cannot prove that the app's environment variables, database, routing, or sign-in callbacks are correct. A working preview address cannot prove that the custom hostname is configured. Keep the results separate so the next fix targets the actual failing layer.

Waiting is not the same as verification

Cloudflare's TTL documentation explains that TTL affects how long DNS responses remain cached. Its proxied records use Auto, currently 300 seconds, and that setting is not editable. The documentation also warns that local caches can make a change take longer to appear.

So "five minutes passed" is not a universal completion test. Nor does lowering a TTL now erase an answer that another resolver already cached under the previous value.

Record when you changed the hostname and what each check returned. If different clients see different results, preserve that distinction instead of repeatedly editing records in response to every refresh.

This is also a limit of rollback: restoring the previous record does not instantly erase every cached answer. Keep the old service available for an appropriate transition period and follow the provider's migration guidance when the stakes are higher than a practice app.

The next useful step

Before you connect a custom domain, fill in one change note and ask AI to challenge its assumptions. Can it identify the exact hostname, supported destination, protected services, expected traffic path, and three independent checks?

That is a better starting point than "fix my DNS." A clearer editor makes a change easier to enter. A clear change note makes it easier to understand and verify.

The $3 Starter Prompts help turn a rough app idea into bounded tasks. The $9 standalone e-book provides the organized path from idea through testing and publication; the $10 learning bundle includes both resources.

Bootcamp Bundle (Review Radar) is coming soon, with a public preview and email waitlist; checkout remains closed.

You can also find me here:

Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Upwork: https://www.upwork.com/freelancers/marcusykim