How DNS makes mistakes invisible
Each DNS record carries a TTL (time to live): how long a resolver may keep the answer before asking again. RFC 1035 defines it as a 32-bit value in seconds and RFC 2181 limits it to 0 through 2,147,483,647, and says it is a maximum, not a promise: a resolver may also keep its own lower limit.
That produces the classic pattern:
- Someone changes a record at 10:00 with a TTL of 3,600 seconds (one hour).
- The person checks the site from their own laptop, which cached the old answer, and it works.
- Over the next hour, visitors whose resolvers refresh get the new, broken value. Some see the site, some do not.
- By 11:00 everyone has the new value and the site is down for everyone.
A mistake can therefore appear up to a TTL after it was made, and look random while it spreads. If you changed something and “it works for me”, you have not tested anything.
The changes that break sites
Deleting or replacing a record you did not read
Zone editors show many records, and some belong to services nobody remembers: a verification record, a mail service, a subdomain used by a booking tool. Before removing a record, find out what consumes it. If you cannot, lower the TTL first and plan to restore it.
Pointing the apex at a CNAME
A CNAME says “this name is an alias for that name”. RFC 2181 section 10.1 states that a name with a CNAME may have no other data, with a narrow DNSSEC exception. The apex of a domain (example.com) always has other records (SOA, NS, often MX), so a plain CNAME there is not valid. Providers offer alias or flattened records as a workaround; check that yours does.
Wrong or stale A and AAAA records
Moving a site to a new host means changing the address. Two things go wrong. A forgotten old record is left in place, so some visitors reach the old server. And an AAAA (IPv6) record points to the old host while the A record points to the new one, so visitors with IPv6 see the old site. Shopify’s manual connection instructions, for example, ask for one A record and one AAAA record at the apex, and ask you to delete other A and AAAA records on the domain; an extra record left from the previous host is exactly the failure above.
Nameserver changes
Changing nameservers at the registrar moves the entire zone to a new provider. If the new zone is missing a record that the old one had (mail, subdomains, verification), it vanishes at the moment of the switch. Copy the old zone completely before you switch, and compare the two lists record by record.
Mail records changed without a mail check
MX, SPF, DKIM and DMARC records live in the same zone as the website’s. A web change can remove or replace them. Email problems after a DNS change get their own guide: Email stops after a DNS change.
Expired or unpaid DNS hosting
If DNS is hosted by the old agency, a former developer or a hosting account the client stopped paying, the zone can disappear with the account. Know where each zone is hosted and who pays.
A safe way to change records
- Export the current zone and keep it with the client’s documentation. A text export is enough.
- Lower the TTL a day ahead (to 300 seconds, say) for the records you will change, so a mistake lasts minutes rather than hours. Wait at least the old TTL after lowering it.
- Make the change as small as possible, one purpose per change.
- Query the authoritative nameserver directly to confirm the new value, then query a public resolver. Tools such as
dig example.com A @ns1.provider.comshow what the zone says without any cache in between. - Test from outside: load the site over HTTPS, check the certificate, check a deep page and check email delivery if mail is involved.
- Raise the TTL again once everything has been right for a day.
- Write down what changed and why. The next person to read the zone will not know.
Catching a change you did not make
Change detection is as valuable as outage detection. A record changed by someone else, by a hosting panel’s one-click action or by a compromised account may not break the site immediately, but it tells you that something moved. Useful signals are:
- A changed A, AAAA, CNAME, MX or NS record on a client domain.
- A new nameserver set.
- An answer that differs by region (a sign of a half-propagated change or geo-routing).
- A certificate that changes shortly after a DNS change, which usually means the hosting changed.
How Beamfar helps
Beamfar records the DNS answers it sees for each monitored site and puts a change on the site’s what-changed timeline. If the site then goes down within the next hour, the incident shows the DNS change just before it, together with what each region saw. It watches the records of the monitored hostname; it does not read your whole zone or test email delivery.
Questions
How long does a DNS change take to take effect?
Up to the TTL of the old record, plus any resolver that keeps its own limit. With a TTL of 3,600 seconds, plan for an hour. With a TTL of 86,400 seconds, plan for a day.
Why does the site work for me but not for the client?
Your device or your resolver cached the old answer or already has the new one, while the client’s does not. Query the authoritative nameserver and a public resolver, and test from another network.
Can I put a CNAME on the root domain?
Not as a plain CNAME. RFC 2181 says a name with a CNAME cannot have other data, and the root always has other records. Use an alias or flattened record if your DNS provider supports one.
Should I lower the TTL permanently?
Not usually. Short TTLs mean more queries and more dependence on your DNS provider answering. Lower the TTL before planned changes and raise it afterwards.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- RFC 1035, Domain names: implementation and specification (www.rfc-editor.org)
- RFC 2181, Clarifications to the DNS specification (TTL, CNAME) (www.rfc-editor.org)
- Shopify Help Center, connecting a third-party domain (help.shopify.com)