Sooner or later, someone asks you to “change a DNS record” — and the panic starts. Yet DNS records are simply the address book of the internet, and there are only a handful you will ever touch. Once you understand what each one does, moving a website or fixing broken email stops feeling like surgery. So let’s translate the jargon into something you can act on.
Domain, registrar, nameservers: who holds what
Your domain is the name you rent, usually for a year at a time. The registrar is the company you rent it from. However, the registrar does not have to hold your DNS. Your nameservers decide which system answers questions about your domain, and those can live at your host, at your registrar, or at a service like Cloudflare. Therefore the first question in any DNS problem is always the same: where do the nameservers point right now?
The five DNS records that matter
- A record — points a name at an IPv4 address. This is what sends
yourdomain.grto your server. AAAA does the same for IPv6. - CNAME — points a name at another name, for example
wwwat your root domain. Handy, because the target can change without you touching anything. - MX — decides where your email is delivered. Change this carelessly and mail stops, even though the website stays up.
- TXT — holds verification strings plus your SPF, DKIM and DMARC policies.
- NS — identifies authoritative nameservers. The registrar sets the parent delegation; your DNS zone also contains NS records.
Notice the split: website and email use different DNS records. If you only change a web address record, leave mail records in place and check for shared dependencies. If you move DNS providers, copy and verify the full zone first, including MX, SPF, DKIM and DMARC records. Cloudflare’s plain-English DNS reference is a useful starting point.
What does CNAME TTL mean?
CNAME TTL is the time, in seconds, that a DNS resolver may normally cache an alias record before checking for a fresh answer. A CNAME TTL of 3600 means one hour; 300 means five minutes. It applies to the alias, not automatically to the target’s A or AAAA records.
For example, these illustrative DNS records give the alias and its target different cache lifetimes:
www.example.com. 300 IN CNAME app.example.com.
app.example.com. 3600 IN A 192.0.2.10Here, the CNAME can normally stay cached for five minutes, while the target address can stay cached for an hour. Changing only the target’s IP address does not shorten that hour because the alias has a lower TTL. If you control both records, plan the TTL of each record you will change. Each resolver’s countdown starts when it caches the answer.
A CNAME points to a hostname, never an IP address or a URL with a path. It cannot normally coexist with other record types at the same name. Consequently, a conventional CNAME cannot sit at the zone apex, which already has SOA and NS records. Provider features such as CNAME flattening handle that case differently.
These caching and alias rules come from RFC 1034. Your provider may also impose TTL limits. For example, Cloudflare uses an automatic 300-second TTL for proxied records; the editable TTL rules differ for DNS-only records.
TTL, propagation and why nothing changes instantly
TTL, or time to live, sets the normal cache lifetime of a DNS answer in seconds. Before a planned change, lower the TTL of the records you will edit, if your provider allows it. Then wait at least the previous TTL before switching their values: lowering TTL does not flush answers already cached. For example, a previous TTL of 86400 requires planning at least 24 hours ahead.
After the change, verify the authoritative answer and several recursive resolvers, then test the site and email. Keep the old service available while you confirm the transition. A short TTL is not a guarantee that every visitor switches within five minutes. Local caches can differ, and some resolvers can serve stale data when refreshing fails. Afterwards, restore a suitable normal TTL to reduce repeated DNS lookups.
A safe checklist before you change anything
First, export the current zone and record which values you intend to change. Second, confirm the new server serves your real hostname correctly, including HTTPS. Third, lower the relevant TTLs and wait out their previous values. Fourth, change only the intended records and verify the result. Finally, test the website and send and receive email. If mail breaks, compare your saved records with our guide to emails landing in spam.
One more habit worth building: keep the domain in an account you control, with the renewal on a card that does not expire quietly. Agencies come and go, but the domain is yours. If you are weighing a host move as well, our comparison of shared, VPS and managed hosting covers where to land. And if you’d rather not touch the zone file at all, our team can run the migration with the mail intact.
