In short
DNS, the Domain Name System, translates a domain name into the server address a browser connects to. Changes seem slow because every resolver between the visitor and your DNS provider caches the previous answer for the record's time-to-live (TTL), which is often set to hours or a day; the '24 to 48 hours' figure is a worst case for records with long TTLs and stale caches. Lower the TTL to a few minutes a day before a change, make the change, and it propagates almost immediately; raise it again afterwards.
What DNS does
Computers connect to IP addresses; people remember names. DNS is the directory in between. When someone types your domain, their device asks a resolver, usually their internet provider's or a public one such as 1.1.1.1 or 8.8.8.8, for the address. The resolver, if it does not already know, asks the root servers, then the servers for the top-level domain, then your domain's authoritative nameservers, which hold the records you set at your DNS provider. The answer comes back, the browser connects, and the whole exchange takes milliseconds.
The records that matter most for a website: A and AAAA records point a name at an IPv4 or IPv6 address; a CNAME points a name at another name, common for www and for hosted platforms; MX records direct email; TXT records hold verification strings and email authentication such as SPF and DMARC; and NS records say which nameservers are authoritative for the domain.
Why changes appear to take 48 hours
Every resolver that has looked up your domain remembers the answer for as long as the record's time-to-live allows. TTL is a number of seconds set on each record, and many providers default to 3600 (an hour), 14400 (four hours), or 86400 (a day). Until the TTL expires, the resolver serves the old answer without asking again.
So when you change an A record, visitors whose resolver cached the old address five minutes ago see the old server for up to a full TTL. Visitors whose resolver has never asked, or whose cache expired, see the new one immediately. The change is not propagating slowly; it is being remembered at different rates in different places, and "24 to 48 hours" is the conservative outer bound registrars quote for records with day-long TTLs plus some resolvers that ignore TTLs and hold answers longer than they should.
Nameserver changes at the registrar, which alter NS records at the top-level domain, are the slowest, because those records commonly carry TTLs of a day or two.
How to make changes fast
- A day or two before the change, lower the TTL on the records you will edit to 300 seconds or less. Wait for the old, long TTL to expire everywhere, which takes as long as the old TTL was.
- Make the change. Resolvers now re-ask within five minutes, and nearly everyone sees the new answer inside that window.
- Keep the old server running until traffic to it stops, for the stragglers.
- Raise the TTL back to a sensible value afterwards, since very low TTLs cost more lookups and slightly slower first connections.
This is the whole trick, and it turns a migration from a two-day period of uncertainty into a five-minute switch. It is part of any zero-downtime deploy or hosting move.
Checking propagation
Query several resolvers directly with dig or nslookup, or use one of the web tools that check dozens of locations at once. If your authoritative nameservers return the new value, the change is made; anything else is caching, and it will clear on the TTL. Your own machine has its own cache too; flush it before concluding anything.
The mistakes that cause outages
Changing nameservers without copying the records. Moving DNS hosting to a new provider with an empty zone takes the site and email down until the records are recreated. Copy every record first, verify the new zone, then switch.
Forgetting email. MX and the TXT records for SPF, DKIM and DMARC live in DNS. A migration that recreates the A record and nothing else moves the website and silently breaks email, which is discovered days later. Email deliverability depends on these records surviving every change.
CNAME at the root. A CNAME on the bare domain conflicts with the other records that must exist there; most providers refuse it, and the ones that allow it use a flattening workaround. Use an A record, or the provider's ALIAS or ANAME equivalent.
Letting the domain lapse. No DNS at all. Everything stops.
Testing from a cache. Changing a record, checking from a machine that cached the old one, and concluding the change failed.
Where to host DNS
Any competent provider will do; the differences are speed of resolution, reliability, and features. Cloudflare, Route 53, and the major registrars' DNS are all fine. Avoid tying DNS to the web host, so that changing hosts never involves moving DNS, and keep the login somewhere two people can find it, since DNS is the one service whose failure takes everything else with it. If you are planning a migration and want the TTL choreography handled, book a call.
Common questions
How long does DNS propagation really take?
As long as the changed record's previous TTL, since every resolver caches the old answer for that period. Records with a one-hour TTL update almost everywhere within an hour; records with a day-long TTL take up to a day, and a few resolvers hold answers longer. Lowering the TTL to five minutes in advance makes a change effectively immediate.
What is TTL in DNS?
Time-to-live, a value in seconds on each record that tells resolvers how long to cache the answer before asking again. Common defaults are one hour to one day. Lower TTLs make changes propagate faster at the cost of more lookups; the standard practice is to lower the TTL before a planned change and raise it afterwards.
How do I change DNS without downtime?
Lower the TTL on the affected records to 300 seconds or less a day or two before the change and wait for the old TTL to expire; make the change; keep the old server running until traffic to it stops; then raise the TTL. Copy every record, including MX and TXT for email, before moving DNS hosting or nameservers.
What is the difference between an A record and a CNAME?
An A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, which is then resolved; it is used for www and for hosted platforms whose addresses change. The bare domain cannot normally be a CNAME because other records must coexist there; use an A record or the provider's ALIAS equivalent.
Why did my email stop working after changing DNS?
Because email depends on MX records and on TXT records for SPF, DKIM and DMARC, and a migration that recreates only the website records leaves them missing at the new DNS provider. Copy every record before switching nameservers, and verify mail delivery immediately afterwards.
