Why You Should Care
Here's the thing: you don't touch DNS every day.
And because you don't touch it every day, you forget. Even after 10 years of engineering work.
I recently launched a new SaaS product and needed to register it with Google Search Console. Simple task, right? Then I opened the DNS settings and stared at the screen.
"Wait... what do I put in 'Host Name' again?"
Honestly, it was a bit embarrassing. But I figured I'm probably not alone. So I'm sharing what I re-learned.
The Quick Answer: Use "@" or Leave It Blank
When Google Search Console asks you to add a TXT record for domain verification:
| Field | Value |
|---|---|
| Type | TXT |
| Host |
@ (or blank) |
| Value | google-site-verification=xxxx... |
| TTL | Default |
That's it. You're done.
Common Mistakes
- Putting
example.comin Host → createsexample.com.example.com(oops) - Putting
www→ that's for subdomains, not root verification
So What Does "@" Actually Mean?
@ = the root of your DNS zone (your domain itself)
Here's how DNS management interfaces work:
Host + Zone = FQDN (Fully Qualified Domain Name)
If your zone is example.com:
| Host | Result |
|---|---|
@ |
example.com. ✓ |
www |
www.example.com. |
example.com |
example.com.example.com. ✗ |
Once you understand this, DNS settings make a lot more sense.
DNS Record Types (You Only Need to Know ~5)
Don't memorize everything. Here's what actually matters:
| Record | What It Does | Memory Trick |
|---|---|---|
| A | Domain → IPv4 address | "A" for Address |
| AAAA | Domain → IPv6 address | Four A's, four times longer |
| CNAME | Creates an alias | "Canonical Name" |
| TXT | Text for verification/config | The "notebook" of DNS |
| MX | Mail delivery destination | "Mail eXchange" |
TXT records are like a general-purpose notebook. Search Console, SPF, DKIM, DMARC, SaaS integrations—they all use TXT.
Why Do We Set Up Both www and Root?
Short answer: Google sees them as different sites.
example.com ≠ www.example.com
Historical Context
Back in the day, subdomains meant different services:
www.example.com → Web
ftp.example.com → FTP
mail.example.com → Mail
www was specifically for "World Wide Web" servers.
What To Do Now
Pick one as your canonical URL and redirect the other:
https://example.com ← canonical
https://www.example.com → 301 redirect
The key is consistency. Pick one, stick with it.
DNS Survival Checklist
A few things I wish I'd remembered before touching DNS:
1. DNS Changes Aren't Instant
There's caching everywhere. TTL (Time To Live) matters. Be patient.
2. Add Before You Delete
❌ Delete old record → hope it works
✅ Add new record → verify → delete old record
3. Root (@) Is Special
- You can't put CNAME on root (usually)
- ALIAS/ANAME are provider-specific workarounds
4. Email Is Fragile
If you touch MX, SPF, DKIM, or DMARC—be careful. Broken email is painful.
5. DNS Is the Foundation
When DNS goes down, everything goes down: web, API, email. All of it.
6. Debug Commands
dig example.com
dig TXT example.com
nslookup example.com
Wrapping Up
DNS is one of those things that's boring when it works and terrifying when it doesn't.
After 10 years of development work, I still had to look up what @ means. And that's okay. We don't touch DNS often enough to keep it all in our heads.
What you actually need to remember:
-
@= root domain - A, CNAME, TXT, MX are your main friends
- Add before delete
- One canonical URL, redirect the other
- Be careful with email records
Hope this helps someone else who's staring at a DNS panel thinking "wait, how does this work again?"
I write about engineering decisions and the thinking behind them at tielec.blog
Top comments (0)