DNS Explained for Website Owners: Records, TTL and Safe Changes

Most DNS outages are not caused by DNS being complicated. They happen because someone edited a record without knowing what else depended on it, or changed nameservers in the wrong place. After reading this guide you will be able to read a zone file, explain what each record type is for, tell which company actually controls your DNS, and make a change with a rollback plan.

How a DNS lookup actually works

When a visitor types www.example.com, their device asks a recursive resolver, usually run by their ISP, their employer, or a public provider. The resolver does the legwork. If it has no cached answer, it starts at the root servers, which refer it to the servers for .com, which in turn refer it to the authoritative nameservers for example.com. Those servers hold the real records and give the final answer. The resolver caches the answer for the length of its TTL and hands it back to the visitor.

Two terms matter in everything that follows:

• Authoritative server: the source of truth for a zone. It answers from its own data and does not cache.
• Recursive resolver: a middleman that asks questions on behalf of clients and remembers answers.

The original specification is in RFC 1034 and RFC 1035, and it has held up remarkably well. What changes in practice is who operates each piece.

Registrar, registry and DNS host are three different things

This is the single most common source of confusion. The registry runs the top-level domain (for example .com). The registrar is the company you pay to register your domain. The DNS host is whoever runs the authoritative nameservers for your zone. They can all be the same company, but often they are not.

The registrar tells the registry which nameservers are in charge of your domain. That list of NS records is what the whole internet follows. If your domain is registered at one company but its nameservers point to a CDN or cloud provider, then records must be edited at the DNS host, not at the registrar. Editing the registrar's old zone editor will change nothing, and many an afternoon has been lost to this.

You can see who is in charge with the Nameserver Lookup tool, or from a terminal:

dig NS example.com +short

The WHOIS Lookup shows the registrar and the nameservers delegated at the registry.

The record types you will actually meet

Every DNS record has a name, a type, a TTL and a value. Here is what each common type does.

A and AAAA

These are the records that put a site on the map. If you publish an AAAA record, IPv6-capable visitors will use it, so it must point to a server that really serves your site over IPv6. A stale AAAA record left behind after a migration is a classic cause of "works for me, broken for some users".

CNAME

A CNAME says "this name is really that other name, go and look it up there". Rules worth remembering:

• A name with a CNAME cannot have any other record type at the same name. This is why a CNAME cannot sit alongside MX or TXT at the same label.
• The zone apex (example.com itself) must carry SOA and NS records, so a standard CNAME is not allowed there.
• Chains work but add lookups. Keep them short.

Many providers offer a workaround for the apex, called ALIAS, ANAME or "CNAME flattening". The DNS host resolves the target itself and returns ordinary A/AAAA records to the world. It is not a standard record type, so it only works at providers that implement it, and the addresses returned depend on where the provider resolves from.

MX

MX records list mail servers with a priority number. Lower numbers are tried first. An MX target must be a hostname with its own A or AAAA record, never an IP address and never a CNAME. Check yours with the MX Lookup.

TXT

TXT records carry SPF, DKIM public keys, DMARC policy, and domain-verification tokens for services like search consoles and SaaS tools. A long value may be split into several quoted strings inside one record, which resolvers join. Mail-related TXT records are covered in the SPF, DKIM and DMARC guide.

NS and SOA

NS records at the zone apex list the servers that answer for your domain. A second set of NS records exists at the parent (the registry), and the two sets should agree. The SOA record carries a serial number, which secondary nameservers use to decide whether to refresh, plus timers for refresh, retry, expire and the negative-caching TTL.

CAA

CAA lets you say which certificate authorities may issue for your domain. If you add one that excludes your current CA, certificate renewal will start failing. Include every CA you use, including any your CDN uses on your behalf.

SRV

SRV records give a priority, weight, port and target, and are used by services such as SIP, XMPP and some directory protocols. Browsers do not use them for ordinary websites.

TTL: the number that governs how quickly changes show up

TTL (time to live) is how many seconds a resolver may cache an answer. A TTL of 3600 means up to an hour of staleness after you change a record. Short TTLs let you move fast and cost slightly more query load; long TTLs are efficient but make mistakes linger. Choose per record. A static marketing site can sit at an hour or more, while a record you expect to move should have a lower value ahead of time.

Not every resolver behaves ideally. Some enforce a minimum or maximum TTL, so the number you set is a request, not a guarantee. The next guide, how long DNS propagation takes, goes deeper on caching and why "propagation" is the wrong mental model.

Looking at DNS with dig

dig is the most honest DNS tool because it shows exactly what a server said. The essentials:

# Ask your default resolver
dig A www.example.com

# Short output
dig AAAA www.example.com +short

# Ask a specific public resolver
dig @1.1.1.1 A www.example.com

# Ask an authoritative server directly (bypasses resolver caches)
dig @ns1.dnshost.example A www.example.com +norecurse

# Follow delegation from the root
dig +trace www.example.com

# MX, TXT, CAA
dig MX example.com +short
dig TXT example.com +short
dig CAA example.com +short

In the answer section, the second column is the remaining TTL in the resolver's cache, which counts down on repeat queries. Asking the authoritative server directly shows the full configured TTL. If you do not have dig, nslookup -type=MX example.com or host -t MX example.com do the same job. For a browser-based view that queries from several places, use the DNS Checker.

A safe procedure for changing DNS

Use this sequence for any change that would hurt if wrong: moving web hosts, changing mail providers, switching DNS hosts.

1. Record the current state. Export the zone or copy every record. Save dig output for the records you will touch. The DNS History tool can help you recover what a zone looked like before.
2. Lower the TTL in advance. Reduce the TTL on the records you will change to something like 300 seconds, at least one full old-TTL period before the change. If the old TTL was 86400, start a day ahead. Lowering it five minutes before the change achieves nothing, because resolvers still hold the old long-lived answer.
3. Prepare the destination first. The new server should already answer correctly for your hostname, for example by testing with curl --resolve www.example.com:443:203.0.113.20 https://www.example.com/.
4. Make the change at the authoritative DNS host.
5. Verify at the source. Query the authoritative servers directly, then a couple of public resolvers.
6. Keep the old service running until the old TTL has expired and traffic has drained.
7. Raise the TTL back once everything is stable.

Common mistakes

• Editing the wrong zone. Changing records at the registrar while nameservers point elsewhere. Always confirm with dig NS.
• Forgetting mail when moving DNS hosts. Missing MX, SPF, DKIM or DMARC records silently break email. Compare the zones record by record, then run the Email DNS Checker.
• Trailing dots. In zone-file syntax, mail.example.com without a trailing dot is relative to the zone and becomes mail.example.com.example.com.. Many web interfaces handle this for you, but not all.
• CNAME next to other records. Creating a CNAME at a name that already has MX or TXT data.
• IP address in MX or CNAME fields. Both require hostnames.
• Leaving stale AAAA records after the IPv4 host changed.
• Orphaned records pointing at services you cancelled. These can become a security problem, covered in subdomain takeover and dangling DNS.
• Very low TTL left forever. Harmless for small sites but unnecessary, and it increases dependence on your DNS host's availability.
• Single DNS provider, no redundancy. Delegating to at least two nameservers is the minimum, ideally on separate networks.

Next steps

• Check what the world sees with the DNS Checker and confirm delegation with the Nameserver Lookup.
• Verify mail records using the MX Lookup and Email DNS Checker.
• Read how long DNS propagation takes before your next migration.
• Protect against lapses with domain expiry grace and redemption.

FAQ

What is the difference between a registrar and a DNS host?

A registrar is where you register and renew the domain and where the nameserver delegation is set. A DNS host operates the nameservers that hold your actual records. They can be the same company, but if your nameservers point elsewhere, record edits belong at that other provider.

Why can't I put a CNAME on my root domain?

The root of a zone must hold SOA and NS records, and a CNAME cannot coexist with other records at the same name. Use A and AAAA records at the apex, or use your DNS host's ALIAS, ANAME or flattening feature if it offers one.

What TTL should I use?

For stable records, values between 1 hour and 1 day are common. Before a planned change, drop to something like 300 seconds, with enough lead time for the old TTL to expire. There is no single correct number, since it trades speed of change against query load and tolerance for mistakes.

Do I need to publish IPv6 AAAA records?

Not required, but beneficial if your host genuinely serves IPv6. Never publish an AAAA record you have not tested, because IPv6-enabled clients will prefer it and fail if it is wrong.

How can I tell if a DNS problem is on my side or the visitor's?

Query your authoritative nameservers directly with dig @ns1... +norecurse. If they answer correctly but a public resolver does not, the issue is caching or delegation, not your zone data.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.