Managing DNS at Your Registrar
Chapter 2 — Managing DNS at Your Registrar
Knowing how DNS works in theory is step one. Step two is being able to make the right changes in the right place quickly and confidently. This chapter covers the practical side: navigating IONOS's DNS panel, adding and editing every record type you'll need, creating subdomains, and verifying that your changes have taken effect.
What this chapter covers: Registrar vs DNS host — understanding where to make changes. The @ symbol and DNS hostname notation. Adding and editing A, CNAME, MX, and TXT records in IONOS step by step. Subdomains — what they are, when to use them, and how to create them. The www vs naked domain debate. Verifying changes with dig. Common mistakes that catch everyone out.
Registrar vs DNS Host — Where Do You Make Changes?
Two different roles are involved in managing a domain, and they're often confused:
- Registrar — the company you bought the domain from. They hold the registration (the right to use the domain name) and control the NS records — the records that point to whichever nameserver is authoritative. IONOS is your registrar for osztromok.com.
- DNS host (authoritative nameserver) — the service that holds your actual DNS records: A, CNAME, MX, TXT, etc. By default this is also IONOS, because when you bought the domain they set up hosting on their own nameservers. If you later move DNS to Cloudflare, IONOS remains your registrar (you still pay them for the domain) but Cloudflare becomes the DNS host.
┌──────────────────────────────────────────────────────┐
│ IONOS (Registrar) │
│ • Holds the domain registration │
│ • Controls NS records (nameserver delegation) │
│ • Currently also the DNS host (both roles in one) │
└──────────────────────────────────────────────────────┘
│
│ NS records point to:
▼
┌──────────────────────────────────────────────────────┐
│ IONOS Nameservers (DNS host) │
│ • Holds your A, CNAME, MX, TXT records │
│ • This is where you add/edit/delete records │
│ • Answers queries from resolvers worldwide │
└──────────────────────────────────────────────────────┘
When you move DNS to Cloudflare (Chapter 3):
• IONOS still = registrar (keeps the registration)
• NS records updated to point at Cloudflare
• Cloudflare becomes the DNS host (you manage records there)
For osztromok.com right now: All DNS management is done inside IONOS — log in, go to Domains & SSL → DNS → click on osztromok.com. Everything in this chapter takes place in that panel.
DNS Hostname Notation — The @ Symbol
When you add a record in a DNS panel, you need to specify which hostname the record applies to. There are three forms you'll encounter:
| What you type | What it means | Example result |
|---|---|---|
| @ | The root/apex domain itself — the domain with nothing in front of it | osztromok.com |
| www | The www subdomain — just type the subdomain label, not the full name | www.osztromok.com |
| blog | Any other subdomain label | blog.osztromok.com |
| *.osztromok.com | Wildcard — matches any subdomain not explicitly defined | anything.osztromok.com |
IONOS uses @ for the root domain in some views and the full domain name in others. If you see a field labelled "Hostname" or "Host", entering @ applies the record to osztromok.com itself. Entering www applies it to www.osztromok.com.
Adding and Editing Records in IONOS
In IONOS, navigate to: Domains & SSL → DNS → select your domain → Add Record. The form fields differ slightly by record type. Here's what to enter for each.
A Record — pointing your domain to an IP address
A Record — Root domain pointing to your server
Type
A
Select from the Type dropdown
Hostname
@
@ means the root domain (osztromok.com itself)
Points to
82.2.236.221
Your server's public IP address
TTL
300
5 minutes — keep low if your IP might change
A Record — Subdomain pointing to the same server
Type
A
Hostname
www
Creates www.osztromok.com
Points to
82.2.236.221
Same IP as the root domain
TTL
300
CNAME Record — alias from one name to another
CNAME Record — www as an alias for the root domain
Type
CNAME
Select CNAME from the Type dropdown
Hostname
www
The alias — www.osztromok.com
Points to
osztromok.com.
The target — note the trailing dot (fully qualified). Some panels add it automatically.
TTL
3600
1 hour — CNAME targets rarely change
A record or CNAME for www? Both work. Use an A record pointing to your IP if you want simplicity and one less DNS lookup. Use a CNAME pointing to your root domain if you want www to automatically follow wherever the root domain points (useful if you change hosts). Never use CNAME for the root domain itself (
@) — only subdomains.
MX Record — for email delivery
MX Record — if you host email yourself
Type
MX
Hostname
@
Email for the root domain (user@osztromok.com)
Points to
mail.osztromok.com.
The mail server hostname (must have its own A record)
Priority
10
Lower number = higher priority. 10 is conventional for a single mail server.
TTL
3600
MX records change rarely — 1 hour is fine
TXT Record — domain verification and SPF
TXT Record — domain ownership verification (example: Google Search Console)
Type
TXT
Hostname
@
Verification TXT records almost always go on the root domain
Value
google-site-verification=abc123xyz
Copy exactly from the service asking for verification — don't add quotes
TTL
3600
Editing an existing record in IONOS: Find the record in the list, click the pencil/edit icon on the right. Change the value (e.g. new IP address), save. The record updates immediately on IONOS's servers — propagation to the rest of the world depends on the current TTL. To delete a record, use the bin/trash icon. Always double-check you're deleting the right record — there's usually no undo.
Subdomains — What They Are and When to Use Them
A subdomain is any label placed in front of your domain: www.osztromok.com, blog.osztromok.com, shop.osztromok.com. In DNS terms, creating a subdomain just means adding a record with that label as the hostname. You don't need to "register" a subdomain — you own the whole domain, including all possible subdomains.
www.osztromok.com
A or CNAME
The traditional web subdomain. Many people expect www to work even if you only advertise the root domain. Worth setting up even if you redirect it to the root.
blog.osztromok.com
A or CNAME
A separate section of your site. Could point to the same server (handled by an Apache VirtualHost — Chapter 5) or a completely different server.
mail.osztromok.com
A record
Mail server hostname. Required if you host your own email. MX records point to a hostname, not an IP — so mail.osztromok.com needs its own A record.
*.osztromok.com
A or CNAME wildcard
Catch-all for undefined subdomains. Anything.osztromok.com will resolve to this record. Useful for development environments or multi-tenant apps.
Important: Creating a subdomain DNS record is only half the job. The DNS record tells the internet which server to connect to — but your web server also needs to be configured to respond to that subdomain. Apache does this with Virtual Hosts (covered in Chapter 5). A DNS record pointing at your server without a corresponding VirtualHost will show Apache's default page or a 404, not your intended content.
The www vs naked domain debate
Should your site be at osztromok.com (naked/apex domain) or www.osztromok.com? The practical answer: set up both and redirect one to the other. Here's how to decide which is canonical:
- Root domain canonical (
osztromok.comis primary, www redirects to it) — simpler to type, looks cleaner. The setup you already have. Apache redirects www → root. - www canonical (
www.osztromok.comis primary, root redirects to it) — historically preferred because CNAME records work on www but not on the root, making it easier to point to CDNs and external services. Less relevant now that Cloudflare handles CNAME flattening.
Either choice is fine. What matters is consistency — pick one and redirect the other so visitors and search engines always land on the same URL.
Verifying Your Changes
# After making a change in IONOS, verify it immediately at the authoritative server.
# This confirms IONOS has saved it — before waiting for propagation elsewhere.
# Find your authoritative nameservers
$ dig osztromok.com NS +short
ns1.ionos.co.uk.
ns1102.ui-dns.org.
# Check the record directly at the authoritative server (no caching)
$ dig osztromok.com @ns1.ionos.co.uk +short
82.2.236.221 # good — authoritative server has the right answer
# Check a specific subdomain
$ dig www.osztromok.com @ns1.ionos.co.uk +short
82.2.236.221
# Check your local resolver — TTL shows how long until the cached copy expires
$ dig osztromok.com +noall +answer
osztromok.com. 247 IN A 82.2.236.221
# TTL=247: your resolver cached this 53 seconds ago (300-247=53). Old value still cached.
# Check what the world sees — query several resolvers
$ dig osztromok.com @8.8.8.8 +short # Google
$ dig osztromok.com @1.1.1.1 +short # Cloudflare
$ dig osztromok.com @9.9.9.9 +short # Quad9
# Or use the online tool dnschecker.org to see dozens of locations at once
Scenario 1 — Your IP Has Changed, Update the A Record
Scenario · Chapter 2 · Scenario 1
Your router was reset and your ISP assigned a new public IP. osztromok.com is now unreachable. Update the A record in IONOS to restore access.
1
Find your new public IP. Run this on your server (or any device on your home network):
$ curl ifconfig.me
86.11.204.43
2
Log in to IONOS → Domains & SSL → DNS → osztromok.com. Find the existing A record for
@ (the root domain). Note the old IP currently shown.
3
Edit the A record. Click the pencil icon next to the
@ A record. Change the IP from the old value to 86.11.204.43. Also lower the TTL to 300 while you're there. Save.
4
If you also have a www A record (not a CNAME), update that too — it points to the same IP and also needs changing.
5
Verify the authoritative server has the new value immediately:
$ dig osztromok.com @ns1.ionos.co.uk +short
86.11.204.43
# Good — the change is live on IONOS. The rest of the internet will follow
# as their cached copies of the old IP expire (within 5 minutes at TTL=300).
This is the manual version of what Dynamic DNS (Chapter 7) automates — a script on your server detects when the IP changes and updates IONOS automatically via their API, so you never have to do this by hand again.
Scenario 2 — Add a www Subdomain
Scenario · Chapter 2 · Scenario 2
osztromok.com works but www.osztromok.com returns "server not found". Add a DNS record so both work, then verify.
1
Confirm www has no record yet:
$ dig www.osztromok.com +short
# no output = no record exists
2
In IONOS, add a new record:
Type:
Or use a CNAME instead:
Type:
Type:
A · Hostname: www · Points to: 82.2.236.221 · TTL: 300Or use a CNAME instead:
Type:
CNAME · Hostname: www · Points to: osztromok.com. · TTL: 3600
3
Verify it immediately at the authoritative server:
$ dig www.osztromok.com @ns1.ionos.co.uk +short
82.2.236.221
4
Test in a browser. DNS now resolves www.osztromok.com to your server's IP — but Apache needs a VirtualHost to respond to it. If you see Apache's default page instead of your site, that's the next step (covered in Chapter 5). If you want www to redirect to the root domain, that's also handled in Apache's VirtualHost config.
DNS and web server configuration are separate concerns. DNS tells the browser which server to connect to. Apache decides what content to serve once the connection arrives. Both need to be set up correctly.
Common Mistakes
Using a CNAME for the root domain (@)
IONOS may let you save it, but most resolvers will ignore it or behave unpredictably. The root domain must use an A record (or AAAA for IPv6). Only subdomains like
www or blog can use CNAME.Adding a CNAME and an A record for the same hostname
A CNAME record cannot coexist with any other record for the same name. If
www has a CNAME pointing to osztromok.com., you cannot also have an A record for www. Delete one before adding the other.Forgetting the trailing dot in CNAME targets
In DNS,
osztromok.com. (with trailing dot) means the fully-qualified root domain. Without the dot, some systems interpret it as relative to the current zone. IONOS usually handles this for you, but if you're editing a zone file directly, always use the trailing dot on target names.Not waiting for the TTL to expire before testing
If you had a long TTL (e.g. 86400), resolvers can serve the old answer for up to 24 hours. Always query the authoritative server directly (
dig domain @ns1.ionos.co.uk) to confirm the change is saved, then be patient for propagation elsewhere.Deleting the wrong record
If you have both an A record and a TXT record for
@, they look similar in the list. Deleting the A record by mistake takes the site down immediately. Always read the Type and Value columns carefully before clicking delete.Thinking DNS change = site immediately works
DNS resolves which server to connect to — the web server itself still has to be running, port-forwarded (or tunnelled), and configured to respond to that hostname. A correct DNS record pointing at a misconfigured or offline server still gives the visitor an error.
Quick Reference — Chapter 2
| Task | Record type | Hostname field | Value field |
|---|---|---|---|
| Root domain → IP | A | @ | Your server's public IP |
| www → same IP | A | www | Your server's public IP |
| www → root alias | CNAME | www | osztromok.com. |
| blog subdomain | A or CNAME | blog | IP or target hostname |
| Email delivery | MX | @ | mail.osztromok.com. (priority: 10) |
| Domain verification | TXT | @ | Verification string from the service |
| Cloudflare Tunnel | CNAME | www (not @) | <tunnel-id>.cfargotunnel.com. |
| Verification command | Purpose |
|---|---|
| dig domain.com @ns1.ionos.co.uk +short | Check authoritative answer immediately after saving — no propagation wait |
| dig www.domain.com +short | Check what your local resolver currently returns (may be cached) |
| dig domain.com +noall +answer | See the TTL — how many seconds until your resolver re-queries |
| dig domain.com @8.8.8.8 +short | Check what Google's resolver currently returns (different cache to yours) |