What's the difference between an A record and a CNAME, and which do I use?

An A record points a domain to an IP address; a CNAME points one domain to another domain name. The root domain (example.com) usually needs an A record or a special CNAME alternative; subdomains (www, blog) often use a CNAME to a provider's address. Your vendor picks, but you should know the difference.

What happens if these are set wrong?

The common results are a site that won't load, email that won't arrive, or an SSL certificate that won't issue. The risk is not cost but 'nobody noticed' — e.g., a wrong MX (mail) record bounces all customer email silently. Always verify item by item after switching.

DNS, A Record, CNAME, TTL: the Four Address Words to Know Before You Switch Hosts (Explained Like Mail Forwarding)

Scene: a cram school changes hosts, the vendor says "lower the TTL first," and the owner is lost

A cram school is moving its site from an old host to a new one. The vendor drops a line on LINE: "I'll change the A record, lower the TTL, leave the CNAME as is; DNS should take minutes to a day." The owner understood "minutes to a day" and nothing else. These four words — DNS, A record, CNAME, TTL — are really four parts of one thing: together they decide which server someone lands on after typing your address, and how fast that direction updates. Understand them once and you will never be bluffed during a host move, a domain change, or an email setup again. We use one analogy throughout: a post office forwarding mail.

DNS: the phone book of the internet

DNS (Domain Name System) translates a human-friendly address (example.com) into the IP address a computer understands (like 203.0.113.5). Analogy: it is the post office's address book — you write "Mr. Wang's Cram School" and the office looks up which street and number to deliver to. Example: a student types your address; the computer first asks DNS "where is this?", DNS returns an IP, and only then does the browser connect. Without DNS, everyone would memorize numbers to reach you.

A record: writing the street number down directly

An A record is a DNS entry that points a domain straight at an IP address. Analogy: writing "Mr. Wang's Cram School → 100 Zhongshan Rd" in the address book. Example: pointing example.com at the new host's IP means editing this A record. When you change hosts, this is usually the core thing you move — the street number, from the old address to the new.

CNAME: an alias that forwards to another name

A CNAME does not point to an IP; it points one domain to another domain name. Analogy: the post office's forwarding service — mail to "branch office" always forwards to "headquarters," so a branch move needs no per-letter rewrite. Example: www.example.com uses a CNAME to a provider's address (like yourshop.platform.com); when they change IP, you do nothing — because you pointed at a name, not a number.

TTL: how long this direction may be remembered

TTL (time to live, in seconds) sets how long DNS servers everywhere may cache a record before re-checking. Analogy: the expiry on the postman's forwarding note — until it expires, he keeps using the old address. Example: a TTL of 86400 seconds (a day) means a change can take up to a day to fully apply; 300 seconds (5 minutes) usually updates in minutes. That is why an experienced vendor lowers the TTL a day or two before a move.

How the four relate (a mental diagram)

Chained together: a user types the address → (DNS) checks the phone book → (A record / CNAME) finds the IP or alias → (TTL) decides how long that answer is remembered. DNS is the whole system; A records and CNAMEs are two ways to give directions (one to a number, one to a name); TTL is the freshness window on that answer. Grasp this chain and you see why "changed but not live yet" is not the vendor stalling — the TTL simply has not expired.

Concrete impact on your decisions

Timeline: move without lowering TTL first and full switchover can take a day, with some users on the old site meanwhile.
Risk: a wrong A record or MX (mail) record makes the site unreachable or bounces all customer email, often unnoticed.
Money: the settings themselves are usually free (included in the domain or DNS service); the real cost is downtime and lost trust when they are wrong, not a config fee.

5 questions to ask your vendor

Will you lower the TTL before the move, and how far in advance?
How long will old and new hosts run in parallel, and how do you ensure no outage?
Besides the site's A record, will you also confirm the email MX records and SSL validation?
Who holds DNS management (the domain account)? Can I get access?
Which records will you verify after switchover — is there a checklist for me?

Common misconception

Most people assume "a DNS change is instant" — it always has a delay set by TTL. Others assume "A records and CNAMEs are interchangeable" — root and subdomain usage differ, and the wrong one breaks SSL or email. Treat the delay as normal and keep the uses straight, and a move stops being scary.

FAQ

Will my site go down when I switch hosts?

Done right, almost never. Lower the TTL first, run hosts in parallel, and shut the old one only after DNS fully switches. Skipping TTL is what causes "some see new, some see old."

Why doesn't a DNS change take effect immediately?

DNS servers cache the old record for the TTL. A day means up to a day; 300 seconds usually minutes.

A record or CNAME — which?

A record points to an IP, CNAME to another domain name. Root domains usually use A records, subdomains often CNAMEs. Your vendor chooses, but you should know the difference.

What happens if these are wrong?

Commonly a site that won't load, bounced email, or an SSL cert that won't issue — often unnoticed. Always verify item by item after switching.

Call to action

Moving hosts, changing domains, or want to understand how your DNS is set today? ScriptWalker can plan a zero-downtime migration with a verification checklist. Free 30-minute technical consultation: