Complete Beginner’s Guide to Domains & DNS: A Records, CNAME, TTL, Propagation, and Subdomains

 If you’re launching a website, setting up a VPS, or connecting a custom email address, you will inevitably deal with DNS. For beginners, DNS can feel confusing because changes don’t always apply instantly, and the terms (A record, CNAME, TTL, propagation) look technical. The good news is: once you understand a few core concepts, DNS becomes straightforward.

This guide explains domain vs hosting vs nameservers, how DNS works in simple terms, what the most important record types do (A, AAAA, CNAME, MX, TXT), why propagation can take time, how to point a domain to a VPS, and best practices for subdomains and DNS structure.

---

1) Domain vs Hosting vs Nameserver (Don’t Mix These Up)

Domain

A domain is your website’s address, like:

• example.com

You register a domain through a registrar (Namecheap, GoDaddy, Cloudflare Registrar, etc.). A domain is basically a “name” you own/rent yearly.

Hosting (Server / VPS / Cloud)

Hosting is where your website/app actually runs:

• shared hosting
• VPS (Ubuntu server)
• cloud platforms (AWS, GCP, Azure)
• serverless platforms

Hosting provides compute, storage, and a web server that serves your site.

Nameservers (DNS provider)

Nameservers tell the internet which DNS provider is authoritative for your domain.

When you point your domain’s nameservers to a DNS provider (for example, Cloudflare), you’re saying:

“Cloudflare is the source of truth for all DNS records for my domain.”

So the flow is:

• Registrar = where you buy/manage the domain
• Nameservers = which DNS provider controls DNS
• DNS records = rules like “example.com → IP address”
• Hosting/VPS = the actual server you connect to

---

2) How DNS Works (Simple Explanation)

DNS is often called “the phonebook of the internet.” Here’s a simplified process:

1. You type example.com in a browser.

2. Your computer asks a DNS resolver (often your ISP, Google DNS, Cloudflare DNS):

   “What IP address is example.com?”

3. The resolver asks the authoritative nameservers for that domain:

   “What records exist for example.com?”

4. The nameserver responds (for example):

   example.com → 203.0.113.10

5. Your browser connects to that IP and loads the website.

The important takeaway:

• DNS does not host your site.
• DNS only points users to where your site is hosted.

---

3) DNS Record Types You Must Know (A, AAAA, CNAME, MX, TXT)

A Record (Address record)

Purpose: Points a domain (or subdomain) to an IPv4 address.

Example:

• example.com → 203.0.113.10
• api.example.com → 203.0.113.10

Use A records when:

• You have a VPS or server with a public IPv4 address.
• You want direct control and simplicity.

AAAA Record

Purpose: Points a domain to an IPv6 address.

Example:

• example.com → 2001:db8::1234

Use AAAA records when:

• Your VPS provides IPv6 and you want IPv6 enabled.
• Your infrastructure supports IPv6 properly.

If your server doesn’t support IPv6, don’t add AAAA “just because.” A broken AAAA can cause some users to have issues.

CNAME Record (Canonical Name)

Purpose: Points a domain/subdomain to another hostname, not an IP.

Example:

• www.example.com → example.com
• blog.example.com → myblogplatform.hostingprovider.com

Use CNAME when:

• The destination is another service that might change IPs (CDN, hosted platform).
• You’re mapping a subdomain to a SaaS (Shopify, GitHub Pages, etc.).

Important rule: A hostname cannot have both a CNAME and other record types at the same time (in most DNS systems). If www is a CNAME, don’t also give it an A record or MX record.

MX Record (Mail Exchange)

Purpose: Tells the world which mail servers receive email for your domain.

Example:

• example.com MX → mail.provider.com

Use MX when:

• You want email like you@example.com.
• You’re using Google Workspace, Microsoft 365, Zoho Mail, etc.

Note: MX is for email receiving, not for websites.

TXT Record

Purpose: A flexible text record used for verification and security policies.

Common TXT uses:

• Domain verification (Google, Facebook, hosting provider)
• SPF (email sender policy)
• DKIM (email signing key)
• DMARC (email authentication policy)
• ACME DNS challenge (advanced SSL setups)

Example:

• example.com TXT "v=spf1 include:_spf.google.com ~all"

---

4) TTL and Propagation: Why DNS Changes Can Take Time

TTL (Time To Live)

TTL is how long resolvers are allowed to cache a DNS answer.

Example:

• TTL = 300 seconds (5 minutes)
• TTL = 3600 seconds (1 hour)

Lower TTL = faster changes (but more DNS queries).

Higher TTL = more stable and efficient (but slower changes).

DNS propagation (what it really means)

DNS changes may appear “slow” because:

• your ISP DNS caches the old record until TTL expires
• your device caches DNS
• different regions/resolvers update at different times

In practice:

• Many changes show up within minutes.
• Some can take a few hours.
• Worst-case “24–48 hours” is usually a safe maximum statement, but many providers update faster.

Best practice: When planning a migration, lower TTL ahead of time (for example, set TTL to 300 seconds one day before changing servers).

---

5) How to Point a Domain to a VPS (A Record to IP)

This is the most common beginner task: “Make my domain open my VPS website.”

Step-by-step (generic DNS provider)

1. Get your VPS public IP (IPv4)
   • Example: 203.0.113.10
2. In your DNS provider, add:

A record for root domain

• Type: A
• Name/Host: @ (or leave blank, depends on provider)
• Value: 203.0.113.10
• TTL: 300 or Auto

A record for www (optional but recommended)

You have two common choices:

Option A (recommended): www points to same IP

• Type: A
• Name: www
• Value: 203.0.113.10

Option B: www points to root using CNAME

• Type: CNAME
• Name: www
• Target: example.com

Either is fine. If you’re on a platform like Cloudflare, CNAME for www is very common.

1. Wait for DNS propagation.
2. Make sure your VPS web server is configured for the domain:
   • Nginx/Apache server_name example.com www.example.com

---

6) Subdomains (app., api., blog.) + Best Practices

A subdomain is anything before your main domain:

• app.example.com
• api.example.com
• blog.example.com

Common patterns for web projects

• www.example.com → marketing/website
• app.example.com → main web application (dashboard)
• api.example.com → backend API
• blog.example.com → blog content / CMS

Best practices

1. Use subdomains to separate concerns
   • Marketing vs app vs API are often deployed differently.
2. Keep API and app separate
   • This helps with security, rate limiting, and scaling.
3. Avoid too many subdomains early
   • Keep it simple unless you truly need separation.
4. Use consistent DNS record types
   • If everything points to the same VPS, A records are simplest.
5. Remember SSL
   • Each subdomain needs HTTPS coverage (use Let’s Encrypt with all hostnames).

Example DNS plan for a single VPS

Assume VPS IP = 203.0.113.10:

• A @ → 203.0.113.10
• A www → 203.0.113.10
• A app → 203.0.113.10
• A api → 203.0.113.10
• A blog → 203.0.113.10

Then on the VPS, Nginx routes each hostname to the correct app/service.

---

7) How to Verify DNS (dig / nslookup / online checkers)

Using dig (Linux/macOS, also available on many systems)

Check A record:

dig example.com A

Check specific resolver (Google DNS):

dig @8.8.8.8 example.com A

Check CNAME:

dig www.example.com CNAME

Using nslookup (Windows/macOS/Linux)

nslookup example.com
nslookup www.example.com

Online DNS checkers

Useful when you want to see results from multiple regions. They can confirm whether propagation is global yet.

---

8) Common DNS Mistakes (and How to Fix Them)

Mistake 1: “Double CNAME” chains

Example:

• www → example.com (CNAME)
• example.com → something-else.com (CNAME)

Some chains work, but too many can cause complexity or failures. Keep it simple.

Mistake 2: Record conflicts (CNAME + A on same host)

If www is a CNAME, don’t also create:

• www A ...
• www MX ...

It will conflict or be ignored depending on provider.

Mistake 3: Wrong host field (@ vs full domain)

Many DNS panels use:

• @ for root (example.com)
• www for www.example.com

Beginners sometimes enter www.example.com in the Name field when the UI expects only www, creating incorrect records.

Mistake 4: Old AAAA record breaking access

If you have an AAAA record pointing to an invalid IPv6, some users may fail to connect. Fix by correcting or removing AAAA.

Mistake 5: “Proxy mode” confusion (CDN)

Some DNS providers (notably Cloudflare) offer a proxy/CDN mode. In proxy mode:

• visitors hit the CDN IPs first
• your VPS IP is hidden
• caching and WAF features may apply

If misconfigured, proxy mode can cause:

• SSL issues (redirect loops)
• wrong origin settings
• trouble validating Let’s Encrypt via HTTP challenge (usually solvable)

If you’re troubleshooting, temporarily switch DNS to “DNS only” (no proxy) to isolate the problem.

---

9) Tips for a Clean DNS Structure for Web Projects

1. Document your DNS

   Keep a simple internal note listing all records and why they exist.

2. Use short TTL during migrations

   Set TTL to 300 before changing infrastructure.

3. Separate app and API

   app. and api. subdomains keep architecture clean.

4. Don’t expose services via DNS you don’t want public

   If a database exists, it shouldn’t have a public DNS record pointing to an open port.

5. Use TXT records for email security early

   If you use domain email, set up SPF/DKIM/DMARC properly to reduce spam and improve deliverability.

6. Prefer A/AAAA for servers, CNAME for platforms

   • VPS → A/AAAA
   • SaaS platforms/CDNs → CNAME

---

Conclusion

DNS is simply the system that converts names like example.com into IP addresses. Once you understand:

• what nameservers do,
• how A/AAAA/CNAME/MX/TXT work,
• why TTL and propagation exist,
• and how to verify records with dig or nslookup,

…you can confidently connect a domain to a VPS, set up subdomains for apps/APIs, and avoid the most common beginner mistakes like record conflicts and proxy misconfigurations.

With a solid DNS foundation, everything else—SSL, deployment, email, and scaling—becomes much easier to manage.