Configuring DNS at Your Registrar
Once you own a domain, you need a place to manage its DNS (Domain Name System — the phonebook of the internet that turns a name like example.com into a server’s IP address). The collection of all the DNS records for one domain is called a zone, and the tool you edit it in is a DNS dashboard. This page shows you where that dashboard lives, how to edit records safely, and why most engineers move their DNS to Cloudflare even when their domain is registered somewhere else.
Where DNS is actually managed
When you buy a domain, two separate jobs happen, and people often confuse them:
- Registration — the company you paid (the registrar, e.g. Namecheap, GoDaddy, Porkbun) records that you own the name.
- DNS hosting — some server somewhere answers the question “what is the IP for
example.com?” These servers are called nameservers.
By default your registrar also hosts your DNS, so the dashboard is right there in your account. But you can point your domain at a dedicated DNS provider instead — like Cloudflare or AWS Route 53 — and manage the zone there. The domain stays registered with the registrar; only the DNS job moves.
| Option | Where you edit records | When to use |
|---|---|---|
| Registrar’s built-in DNS | Inside your registrar account | Fine for a quick, simple setup; one or two records |
| Cloudflare DNS (free) | Cloudflare dashboard | Recommended default — fast, free, adds caching/security |
| AWS Route 53 (paid) | AWS console | When your infra is already on AWS and you want IaC integration |
Moving DNS to a dedicated provider does not transfer your domain. You keep paying the registrar for the name; Cloudflare just answers the DNS queries.
Editing records in the dashboard
Every DNS dashboard, whether at a registrar or Cloudflare, shows the same core fields for each record:
| Field | Meaning | Example |
|---|---|---|
| Type | The kind of record | A, CNAME, MX, TXT |
| Name | Which hostname this applies to | @, www, api |
| Value / Content | What it points to | 203.0.113.10 |
| TTL | Time To Live — how long resolvers cache it, in seconds | 3600 (1 hour) |
To add a record you pick the type, fill in the name and value, set a TTL, and save. Changes take effect after the old cache expires, which is why a low TTL (like 300 seconds) is handy while you are still making changes — resolvers re-check quickly. Raise it back to 3600 once things are stable.
The @ and www conventions
Two name values trip up almost every beginner:
@means the root (or “apex”) of your domain —example.comitself, with nothing in front. Some dashboards show a blank name or the full domain instead of@; they all mean the same thing.wwwis just a subdomain namedwww, giving youwww.example.com. It is not special or required — it is a convention from the early web.
A typical website needs both: an A record on @ pointing to your server’s IP, and either an A or a CNAME on www so both addresses work.
| Name | Type | Value | Result |
|---|---|---|---|
@ | A | 203.0.113.10 | example.com -> your server |
www | CNAME | example.com | www.example.com -> same place |
You can verify a record from your Ubuntu server (Ubuntu 22.04 / 24.04 LTS) with dig, the standard DNS lookup tool. Install it first if it is missing:
sudo apt update
sudo apt install -y dnsutils
dig +short example.com AOutput:
203.0.113.10To check the www record and follow the CNAME chain:
dig +short www.example.comOutput:
example.com.
203.0.113.10If you change a record and want to see what is currently live without your machine’s cache, query a public resolver directly:
dig @1.1.1.1 +short example.com AOutput:
203.0.113.10Why Cloudflare for DNS
Cloudflare offers free DNS hosting that is faster and more reliable than most registrars, with a clean dashboard and extra features at no cost. To use it you sign up, add your domain, let it import your existing records, then change your nameservers at the registrar to the two Cloudflare gives you (e.g. dana.ns.cloudflare.com). After that, you edit the zone in Cloudflare.
Proxied vs DNS-only
In the Cloudflare dashboard each A or CNAME record has an orange cloud toggle:
- Proxied (orange cloud) — traffic for that record flows through Cloudflare first. Cloudflare hides your server’s real IP, blocks attacks, caches static files, and gives you free SSL. The IP returned in a public lookup is a Cloudflare IP, not yours.
- DNS-only (grey cloud) — Cloudflare just answers the lookup with your real IP and steps out of the way. No caching, no IP hiding.
| Mode | Use it when |
|---|---|
| Proxied (orange) | Normal websites and APIs — you want caching, DDoS protection, and a hidden origin IP |
| DNS-only (grey) | SSH, mail servers, or any non-HTTP service, and A records you point your own SSL certificate at |
If you run Certbot on your own server to get a Let’s Encrypt certificate using the HTTP challenge, set the record to DNS-only (grey) during issuance — a proxied record can hide your server from the validation request and make issuance fail.
When proxied, check the headers to confirm Cloudflare is in front:
curl -sI https://example.com | grep -i serverOutput:
server: cloudflareBest Practices
- Keep TTL low (300s) while making changes, then raise it to 3600s once stable.
- Always create both the
@andwwwrecords so the site works either way. - Move DNS to Cloudflare for free speed, security, and SSL — but remember the domain stays at your registrar.
- Set non-HTTP records (SSH, mail) and Certbot-validated records to DNS-only.
- Verify every change with
dig @1.1.1.1before assuming it is live, since local caches lie. - Never paste your real origin IP into a proxied record’s public-facing service if hiding it is the goal — use the grey cloud only where needed.