Domains and DNS in practice: your site’s zone and a move with no downtime

A DNS zone is the list of a domain’s records: A, CNAME, MX, TXT. The zone in force is the one the domain’s NS servers at the registrar point to.

Three companies and one domain

Three parties work with a domain at once, and mixing them up is the commonest reason for “I changed everything and nothing happened”.

• The registrar is the company you bought the name from. It records in the registry (for example the registry of the .com zone, run by Verisign under ICANN’s rules) that the name is yours, and says whose NS servers answer for the zone. There are many registrars, ICANN accredits them, and the name is registered to a person or an organization. Since the GDPR most registrars hide the owner’s personal details in the public lookup.
• DNS hosting is the servers that hold your zone: the list of the domain’s records. Often this is the registrar’s own DNS, but it can be your host’s DNS, a cloud provider’s, or a separate service such as Cloudflare.
• Site hosting is the computer the A record points to. From the first lesson of this part you know it’s a separate purchase.

The main rule: the zone in force is the one the domain’s NS point to. If the domain’s NS point at the registrar’s DNS and you changed a record in your host’s panel, you fixed a copy nobody asks for. So the first check for any DNS problem is one: dig example.com NS (or the same in an online tool), and you edit where those servers lead.

Check yourself: where do you edit a domain’s records if the NS point at the registrar’s DNS?

In the registrar’s DNS panel. Any other copy of the zone (at the host, at a service) isn’t used until the NS are switched to it.

What a zone looks like

The records you met in the lesson on DNS hold nothing new. In practice, though, they are read as text. Each line of a zone is a name, a TTL, a type and a value:

@      300   A      192.0.2.10
www    300   CNAME  example.com.
@      3600  MX     10 mail.example.com.
@      3600  TXT    "v=spf1 include:_spf.mail.example ~all"
_dmarc 3600  TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The addresses here are made up: 192.0.2.10 comes from a block reserved for documentation. Three small things trip people up.

• @ means the domain itself (the root), and www means the subdomain www.example.com.
• A dot at the end of a name (example.com.) means “the full name, add nothing”. Some panels want the dot and others add it for you. If a panel without the dot ends up with example.com.example.com, it has added the domain a second time.
• Every panel turns these lines into its own fields, but the meaning is the same: name, type, value, TTL.

The root and www

Visitors type both, example.com and www.example.com, and both should open the site. It looks as if a CNAME at the root would do, but that’s a trap: by the rules of DNS a CNAME has to be the only record on its name (RFC 1034), and the root always holds the service records NS and SOA, and often MX and TXT as well. So:

• the root gets an A record (and AAAA for IPv6) with the server’s address. When a platform’s address changes and its documentation doesn’t promise otherwise, ask your DNS provider for ALIAS/ANAME or “CNAME flattening”, where the provider fills in the current address itself;
• www gets a CNAME to the root, or to the name the platform gave you.

And one more decision, which helps search as well: choose one main address and redirect the other to it with a permanent 301 redirect, as in the lesson on HTTP. Then the site has one address for people and search engines, not two identical ones.

Languages: a folder, a subdomain or a domain

If the brief has a second language, you need to decide where it lives. There are three ways.

1. A folder: example.com/es/. Nothing changes in DNS, there’s one certificate, and the domain’s weight is shared. For a small site this is usually the best choice.
2. A subdomain: es.example.com. It suits a language with a server or an application of its own. There’s one more record in DNS, and the certificate has to cover the subdomain.
3. A separate domain: example.es. It’s a separate market or brand: you pay for it separately, and the site’s weight is split in two.

Whichever you choose, the pages are tied together with the hreflang attribute, as in the part on HTML. Subdomains aren’t only for languages: status.example.com for a status page, app.example.com for an application, blog.example.com if the blog lives on another service.

Mail and proofs in the zone

A zone has three “outside” jobs, and all of them are written into the same file.

• MX says where to deliver mail. If an outside service runs your mail (Google Workspace, Microsoft 365, Fastmail and others), it gives you the exact values. An MX value is always the name of a server, never an IP address, and that name must not be a CNAME.
• SPF, DKIM and DMARC are TXT records, described in detail in the part on email. Two practical things matter here: there must be one SPF record on a domain (two break the check, so you merge the rules into one), and DMARC starts at p=none while you watch the reports.
• TXT for proof of ownership. Google Search Console, Bing Webmaster Tools, cloud services and platforms ask you to put a special string in a TXT record so they can be sure the domain is yours. You can leave such records for as long as you use the service.

A CAA record is a useful addition: it lists which certificate authorities may issue certificates for the domain. For a small site it’s optional protection, and it comes up in the next lesson.

Play with the diagram. On the first tab you move to a new server and see how many visitors still go to the old one: change the TTL and the time when you shortened it. The second tab checks a zone written as text: the example has several mistakes at once, so find and fix them.

Moving to a new server Check a zone

The record’s TTL now 5 minutes1 houra day Shortened in advance to 1 minute5 minutes1 hour how many hours before the move not shortened1 h before6 h before24 h before48 h before

Time since the record changed: 30 min

• sees the new server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server
• sees the old server

1 of 30 visitors already see the new server, 29 still see the old one. The longest an old answer can live is about 24 h. First shorten the TTL and wait at least the old period: until it runs out, caches keep the long answer.

Dark dots see the new server and light ones still see the old. That is why the old server isn’t switched off at once: it has to live until the longest cache expires.

Check yourself: why do you shorten the TTL ahead of time before a move, not at the moment you change the record?

Because caches keep an answer for as long as the TTL said when they got it. If you shorten the TTL and change the record at once, many visitors will still hold the old answer for a whole day. The long caches need time to expire before the move.

Moving with no downtime

This is the usual order, and it works for any site.

1. Two days ahead, shorten the TTL of the records you’ll change to 300 seconds. Wait at least the old period: until it runs out, caches hold the long answer.
2. Prepare the new server and test it without touching DNS: many platforms give a temporary address, and on your own computer you can temporarily map the name to the IP in the hosts file.
3. At the chosen hour, change the A record (or the CNAME’s value) to the new address. From this minute new requests go to the new server, and old ones burn out as caches expire.
4. Check: dig +short example.com, from different networks (home internet and mobile), on several public resolvers. Don’t forget the browser and the system, which have caches of their own.
5. Wait a day and don’t switch the old server off: some visitors still go to it. Then put the TTL back to a sensible value (an hour) and only after that release the old host.

If something goes wrong, a rollback is the same edit in reverse, and a short TTL is what makes it fast. That’s the whole point of the preparation.

Mistakes that cost a site

Some troubles happen not at a move but years later. Remember four.

• The domain expires. The renewal isn’t paid, and the site, the mail and everything else disappear. Turn on auto-renewal and give an email address you read.
• The registrar account belongs to a contractor. A freelancer “set everything up” and registered the domain to themselves. When you part ways, the domain may turn out to be someone else’s. A domain is registered to you or your organization, and a contractor is given access to the zone.
• One email for everything. The email the registrar account uses is tied to the recovery of every password. Lose it, and you lose the domain with it.
• Forgotten records. After a move, a stranger’s site can end up on your old IP address, and attackers make use of this. Delete records you no longer need.

How to look yourself

dig +short example.com A       # the site's address
dig example.com NS             # whose zone is in force
dig @1.1.1.1 example.com A     # another resolver's answer, for comparison
nslookup example.com           # the same without dig (it is on Windows)

The TTL in an answer counts down on repeated queries: it’s what is left of the cache, and it shows how much longer the old answer will live.

Practice

In front of you is your site, and under it a zone table and a moving plan. Enter the type, the value and the TTL for six records, then in the paragraphs say where the brief’s languages live and who the domain is registered to, and write out the five steps of the move. Take the example address from the block 192.0.2.x: those are addresses for documentation, and your host will give you a real one.

What was wrong before

In 2010 DNS was changed by an email to the host or in a registrar panel where “NS” was something mysterious, and mail and site were often tied to the same account. Few people had heard of SPF and DKIM, and mail from a domain was easy to forge. A move was done at night in the hope that “DNS would spread”. Now it’s a list of five steps, and it doesn’t need a night.