Skip to main content

Domains, DNS, and Resolution Paths

When building a site for the first time, domains and DNS are usually the first things that confuse people.

Because they involve several things at once:

  • Where to buy a domain
  • Where to change resolution settings
  • What A, AAAA, and CNAME mean
  • What a Nameserver is
  • Why a record change does not take effect immediately

The Most Important Thing to Know First​

A domain name is just a name. DNS is responsible for telling the world "where this name should go."

So:

  • Buying a domain does not mean the website is already accessible
  • Having a server does not mean users can reach it through a domain
  • Changing a record does not mean it will take effect across the internet right away

The Roles You Will Actually Encounter​

Domain Registrar​

This is where you buy your domain, such as Aliyun, Tencent Cloud, Namecheap, etc.

DNS Provider​

This is the service that hosts your resolution records. It can be the same company as your registrar, or a different one.

Nameserver​

The Nameserver determines which DNS provider is ultimately responsible for resolving this domain.

If you connect your domain to Cloudflare, the most critical step is often not changing a specific A record, but changing the domain's Nameservers to the set provided by Cloudflare.

The Most Common DNS Record Types​

A Record​

Points a domain to an IPv4 address.

example.com -> 203.0.113.10

AAAA Record​

Points a domain to an IPv6 address.

CNAME Record​

Points one domain alias to another domain.

www.example.com -> example.pages.dev

This is very common with static hosting, CDN integration, and platform hosting.

MX / TXT​

These are not the same thing as website access, but they are frequently used for email verification, SPF, DKIM, site verification, and third-party service integration.

How a Resolution Request Works​

When a user visits docs.example.com, the simplest way to understand the flow is:

  1. The browser first checks local cache and system cache
  2. If not found, it asks a recursive DNS resolver
  3. The resolver looks up the record based on the domain's authoritative DNS information
  4. It ultimately gets an IP or another target domain
  5. The browser then establishes the connection

You do not need to memorize every step of recursive queries like an exam answer, but you should know:

  • DNS itself has caching
  • So your changes will not sync globally immediately

What Is TTL​

TTL can be simply understood as "how long this resolution result can be cached."

Shorter TTL:

  • Changes usually take effect faster
  • May result in more queries

Longer TTL:

  • Caching is more stable
  • Changes take longer to propagate

For a first site, the important thing is not to set TTL to an extreme value, but to understand "why do others still see the old result even though I already changed it."

The Most Common Resolution Scenarios for Building a Site​

Scenario 1: Bare Domain Pointing to a Server​

example.com -> A -> 203.0.113.10

Scenario 2: www Pointing to a Hosting Platform​

www.example.com -> CNAME -> your-site.pages.dev

Scenario 3: Entire Site Behind Cloudflare​

Domain Registrar
  ↓
Nameservers point to Cloudflare
  ↓
Manage DNS records in the Cloudflare console

The Most Common Beginner Mistakes​

1. Changing Records in the Wrong Place​

You changed a bunch of records at the registrar, but the authoritative DNS has already moved to Cloudflare. Those changes will not take effect.

2. Confusing Nameservers with Regular Records​

Nameservers control "who manages resolution." A/CNAME/TXT records control "how to resolve specifically." These are different layers.

3. Only Configuring www or the Bare Domain​

Many people only make example.com accessible but forget www.example.com, or the other way around.

4. Confusing DNS Resolution with HTTPS​

A domain pointing to the right place does not mean the certificate is correct. A correct certificate does not mean the redirect configuration is right.

Practical Advice for Your First Site​

For a personal site or documentation site, you usually need to clarify at least these things:

  1. Whether you want to support both the bare domain and www
  2. Who ultimately manages the DNS
  3. Whether your origin is a hosting platform, object storage, or your own server
  4. Whether you want to add a proxy/CDN layer in front of DNS

A Simple but Useful Approach​

If you are not yet fully comfortable, try to keep:

  • Clear domain ownership
  • Clear authoritative DNS
  • Clear purpose for each record
  • No blind changes in multiple places at once

DNS is not hard. The real difficulty is making random changes when the roles are not yet clear.