Skip to content

Creating DNS records on Cloudflare

Every DNS record this course has covered so far — A, CNAME, MX, and the rest — was read from the outside, with dig, against zones you don't control. This lab creates one, watches it propagate, and confirms with the same tools this course already used that the record actually behaves the way its type promises.

Goal and end result

By the end of this lab, you'll have created a real DNS record in a zone you control, watched a public resolver pick it up, and directly observed the practical effect of Cloudflare's proxy toggle — the same "orange cloud versus grey cloud" choice every Cloudflare user eventually has to understand, now grounded in an actual query rather than a dashboard tooltip.

Requirements

  • A domain you own, with its nameservers already pointed at Cloudflare and the zone showing as active in the Cloudflare dashboard. Setting up a domain on Cloudflare from scratch is outside this lab's scope; this lab assumes that step is already done.
  • dig, already covered in its own dedicated article.

Safety note

Creating or changing a DNS record on a domain that's actually in use — one with a live website, working email, or any other service depending on its current records — can break that service the moment the change propagates. This lab uses a throwaway subdomain (lab.<your-domain>) specifically so nothing already relying on the domain's existing records is affected.

Never practice on a domain's apex or existing records without a rollback plan

Changing or deleting a record that mail, a website, or any other live service currently depends on can take that service down the moment the change propagates — and DNS changes don't undo themselves. If you must practice on records you're not certain are unused, note every current value first (dig <record-type> <name>) so you can restore it exactly, and prefer creating a new subdomain for practice over touching one you're not sure is safe to change.

Step 1: read the zone's current state before changing anything

dig NS <your-domain>

;; ANSWER SECTION:
<your-domain>.      86400   IN  NS  ns1.cloudflare.com.
<your-domain>.      86400   IN  NS  ns2.cloudflare.com.

Confirming the domain's nameservers actually point at Cloudflare, using the exact same NS query the DNS records introduction already covered, is worth doing before anything else — a record created in the Cloudflare dashboard for a zone whose nameservers point elsewhere will never be served to the public internet at all, regardless of how correctly it's configured on Cloudflare's side.

Step 2: create an A record through the dashboard

In the Cloudflare dashboard, open the domain's DNS page, click Add record, and create:

  • Type: A
  • Name: lab
  • IPv4 address: 203.0.113.10 (a documentation-reserved address from RFC 5737 — safe to use for this lab since nothing is actually expected to answer at it)
  • Proxy status: set to DNS only for this first pass — the grey cloud, not the orange one

Cloudflare's own documentation describes the record-creation flow as selecting the record type, filling in its required fields, and saving — nothing more elaborate happens underneath the dashboard than what this course's own A record article already described a zone file entry as being.

Step 3: confirm the record with dig

dig +short A lab.<your-domain>

203.0.113.10

An exact match to the address entered in step 2 confirms the record is live and resolving publicly — this query went to a real, public resolver, not anything Cloudflare-specific, which is exactly the confirmation this lab needs: the record isn't just saved in a dashboard, it's actually being served to the rest of the internet.

Step 4: toggle proxy status and watch the answer change

Back in the dashboard, click the cloud icon next to the lab record to switch it from DNS only to Proxied — the orange cloud. Cloudflare's own documentation for this toggle is direct about what changes underneath it: with a proxied record, "DNS lookups for your application's URL will resolve to Cloudflare anycast IPs" instead of the address actually entered, in contrast to an unproxied record, which "returns your origin's IP address directly."

dig +short A lab.<your-domain>

104.21.xx.xx
172.67.xx.xx

The address Cloudflare now returns is nothing like 203.0.113.10 — it's one of Cloudflare's own anycast addresses, the exact anycast mechanism this course already covered, standing in front of whatever address was actually configured. This is the entire point of proxying: the public DNS answer no longer reveals the origin server's real address at all, and any request to lab.<your-domain> now reaches Cloudflare's edge first, which would attempt to reach 203.0.113.10 itself as the origin behind the scenes — something that will visibly fail in this lab, since that address is deliberately unreachable, which is exactly why this step uses a documentation-reserved address rather than a real server.

A proxied record hides the origin's real address from public DNS; an unproxied record hands it out directly. That's the entire practical difference behind the cloud-icon toggle, confirmed here by two different dig answers to the identical query.

Step 5: check the TTL Cloudflare actually applied

dig A lab.<your-domain>

;; ANSWER SECTION:
lab.<your-domain>.  300 IN  A   104.21.xx.xx

That 300 is the record's TTL in seconds — the same caching-lifetime field the TTL article already explained. Cloudflare's dashboard offers an "Auto" TTL setting for proxied records specifically, which it manages on its own rather than exposing as a value you set directly — this is why a proxied record's TTL is worth checking rather than assumed, since it isn't always the exact number you might expect from the dashboard's own input field.

Troubleshooting

  • dig shows no answer at all for the new record, minutes after creating it. Confirm you're querying a public resolver and not one that's cached a negative result from before the record existed — appending @1.1.1.1 or @8.8.8.8 to the dig command forces the query to a specific, well-known public resolver rather than whatever the local machine defaults to.
  • The proxied record's dig answer doesn't change from the unproxied one. A local or ISP resolver cache holding the previous answer for the remainder of its TTL is the most common cause — the same caching behavior the TTL article already covered, here working exactly as designed rather than indicating a problem with the change itself.
  • A real service on the same domain breaks after this lab. This is exactly the risk the safety note above exists to prevent — if it happens, restore the affected record to its previous value immediately using whatever was noted before this lab began.

Cleanup

Delete the lab record from the Cloudflare dashboard once finished, and confirm it's actually gone from public DNS:

dig +short A lab.<your-domain>

An empty result confirms the record no longer resolves — though a resolver that already cached the previous answer may continue returning it until that cached entry's TTL expires, which is expected and not a sign the deletion failed.

Evaluation criterion

You've completed this lab correctly if you can show, from your own dig output: the record resolving to the address you configured while unproxied, a visibly different address once proxied, and the record's actual TTL as reported by a live query rather than assumed from the dashboard.

Every record this lab touched lived entirely in DNS, resolved before any connection to an actual server was attempted. The next lab moves past resolution entirely, into a service that has to actually be reachable and encrypted once a client has an address to connect to — setting up a VPN a real client can tunnel through.

Sources