Skip to content
Go back

Cloudflare DNS: Beyond Pointing Records

By SumGuy 8 min read
Cloudflare DNS: Beyond Pointing Records

Your Registrar’s DNS Panel Is Fine. Cloudflare’s Is Better.

When you buy a domain, your registrar gives you a DNS panel. It works. You can add an A record, maybe a CNAME, call it a day. But if you’re self-hosting anything serious — a home lab, a VPN, email — you’re going to hit the wall fast.

Cloudflare’s DNS is free, global, and backed by one of the fastest resolver networks on the planet (1.1.1.1 is theirs). Moving your domain’s nameservers to Cloudflare is a five-minute job that unlocks proxying, DDoS protection, Transform Rules, DNSSEC, a real API, and dynamic DNS for your home IP that changes every 48 hours. Let’s walk through all of it.


Step Zero: Make Cloudflare Your Authoritative NS

Before any of this matters, your domain needs to delegate to Cloudflare’s nameservers. Add your domain in the Cloudflare dashboard, import your existing records (it auto-scans), then log in to your registrar and replace the nameservers with the two Cloudflare gives you — something like ada.ns.cloudflare.com and bob.ns.cloudflare.com. DNS propagation takes a few hours. After that, Cloudflare owns your zone.


Record Types That Actually Matter

You probably know A records (IPv4) and CNAME (alias to another hostname). Here’s the rest of the lineup you’ll actually use:


The Orange Cloud vs. The Grey Cloud

This is the one that trips people up. Every record in Cloudflare has a proxy toggle — the orange cloud vs. the grey cloud.

Orange cloud (proxied): Traffic goes through Cloudflare’s network first. Your real server IP is hidden. You get CDN caching, WAF, DDoS mitigation, and free SSL termination. Cloudflare becomes the face of your service.

Grey cloud (DNS only): Cloudflare just resolves the record. The client connects directly to your IP. No hiding, no CDN, no WAF.

When to use grey cloud:

Rule of thumb: web things go orange, everything else goes grey.


TTL Strategy: Don’t Set It and Forget It

TTL (Time To Live) controls how long DNS resolvers cache your records. Cloudflare sets proxied records to “Auto” (5 minutes), which is fine. For grey cloud records, you control it manually.

Before a migration: Drop TTL to 60–120 seconds a day before you cut over. When you flip the record, the old value expires fast and traffic follows quickly.

After a migration: Bump TTL back up to 3600+ seconds. High TTL = fewer DNS queries = faster resolution for your users because more of them hit cache.

Don’t sleep on this. Coming in hot with a 24-hour TTL and then trying to migrate your server is a bad time. Your 2 AM self will appreciate the low TTL buffer.


DNSSEC: Sign Your Zone

DNSSEC adds cryptographic signatures to your DNS records. Without it, nothing stops a resolver from serving forged DNS responses (DNS spoofing / cache poisoning). With it, resolvers can verify the records are actually yours.

Enabling it on Cloudflare takes 30 seconds:

  1. Go to your domain in the Cloudflare dashboard
  2. Click DNSSettingsDNSSECEnable DNSSEC
  3. Cloudflare gives you a DS record (Delegation Signer)
  4. Go to your registrar and add that DS record in their DNSSEC section

That’s it. Cloudflare handles key rotation automatically. If your registrar doesn’t support DS records, that’s a registrar problem — consider it a sign to move your domain.


Dynamic DNS for Your Home Lab

Here’s the feature that makes homelab people’s eyes light up. Your ISP assigns you a dynamic IP. It changes. Maybe every 48 hours, maybe every few days. You’re tired of logging into Cloudflare to manually update your A record every time you lose SSH access to your home server.

The Cloudflare API fixes this with a tiny script you run on a cron job.

You need:

Terminal window
# Get your record ID (replace ZONE_ID and TOKEN)
curl -s -X GET "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records?type=A&name=home.example.com" \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" | python3 -m json.tool

Once you have the record ID, here’s a Python script that updates it automatically:

ddns_cloudflare.py
#!/usr/bin/env python3
import requests
import json
ZONE_ID = "your_zone_id_here"
RECORD_ID = "your_record_id_here"
TOKEN = "your_api_token_here"
RECORD_NAME = "home.example.com"
def get_public_ip():
return requests.get("https://api.ipify.org").text.strip()
def update_dns(ip):
url = f"https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/dns_records/{RECORD_ID}"
headers = {
"Authorization": f"Bearer {TOKEN}",
"Content-Type": "application/json"
}
payload = {
"type": "A",
"name": RECORD_NAME,
"content": ip,
"ttl": 120,
"proxied": False # grey cloud for non-HTTP services
}
r = requests.put(url, headers=headers, json=payload)
return r.json()
if __name__ == "__main__":
ip = get_public_ip()
result = update_dns(ip)
if result.get("success"):
print(f"Updated {RECORD_NAME}{ip}")
else:
print(f"Failed: {result.get('errors')}")

Drop this in a cron job running every 5 minutes:

Terminal window
# Add to crontab (crontab -e)
*/5 * * * * /usr/bin/python3 /home/you/ddns_cloudflare.py >> /var/log/ddns.log 2>&1

Your home lab now has effectively-static DNS without paying for a static IP. This alone is worth moving to Cloudflare.


Page Rules Are Dead. Use Transform Rules.

If you’ve been using Cloudflare for a while, you might have old Page Rules lying around. Cloudflare deprecated them — the replacement is Transform Rules (for URL rewrites and header manipulation) and Redirect Rules (for 301/302 redirects).

The new rules engine is in Rules in the sidebar. It’s more powerful and not capped at 3 rules on the free plan the way Page Rules were. If you have Page Rules, migrate them. Cloudflare has a migration guide, but honestly most simple redirects (/old-path/new-path) just become a single Redirect Rule.


Wildcard Subdomains: *.example.com

Sometimes you want every subdomain to resolve without creating individual records. Add a single A record with the name * pointing to your server’s IP. Now anything.example.com resolves to your server and you can handle routing in Nginx, Caddy, or Traefik.

Grey cloud this one unless you specifically want Cloudflare to proxy all of them. Wildcard proxying is a paid feature (requires at least Cloudflare Pro).


Email Setup: MX, SPF, DKIM, DMARC

If you’re running your own email (good luck, brave soul), here’s the minimum viable DNS setup:

MX record — tells the world where to deliver email for your domain:

Type: MX
Name: @
Content: mail.example.com
Priority: 10

SPF (TXT record) — tells receiving servers which IPs are allowed to send email as you:

Type: TXT
Name: @
Content: v=spf1 mx a:mail.example.com ~all

DKIM (TXT record) — cryptographic signature your mail server attaches to outgoing mail. Your mail server generates the public key; you put it in DNS:

Type: TXT
Name: default._domainkey
Content: v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY_HERE

DMARC (TXT record) — policy for what to do with mail that fails SPF/DKIM:

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Start with p=none (monitor mode), check the aggregate reports, then tighten to p=quarantine or p=reject once you’re confident nothing legitimate is failing.

All of these records go grey cloud — never proxy anything mail-related.


The Summary You Can Screenshot

Cloudflare’s free tier covers 99% of what a homelab or small site needs. The only time you’re paying is for wildcard proxying, advanced WAF rules, or Workers with heavy usage. For everything covered here? Free.


Share this post on:

Send a Webmention

Written about this post on your own site? Send a webmention and it may appear here.


Previous Post
Multi-Stage Docker Builds: Stop Shipping Your node_modules to Production
Next Post
LiteLLM & vLLM: One API to Rule All Your Models

Related Posts