How to Prevent DNS Failures and Domain Lapses on Client Sites

HTTP errors come with a status code and server failures leave logs. When DNS fails, the site simply stops being where its name says it is. Visitors get "this site can't be reached", or someone else's page.

For a freelancer with client sites, three causes cover most of it:

• The domain lapsed. Auto-renewal failed because the card on file expired, or the renewal reminders went to an address nobody reads, such as the client's old one.
• A record went wrong in a migration. The A record still points to the old server, or a typo points it nowhere.
• Nameservers were changed. Someone moved the domain to a new DNS provider, or a registrar transfer changed them, and the records were not recreated at the new place.

What really happens when a domain expires

For generic domains such as .com, .net and .org, ICANN's Expired Registration Recovery Policy sets the sequence:

1. The registrar sends reminders to the registered name holder, usually by email: about a month and about a week before expiry, and at least one more within five days after. If the client registered the domain, the reminders go to the client.
2. After expiry, the registrar must interrupt the domain's DNS resolution path. The name then either stops resolving or leads to the registrar's landing page, which has to say that the registration expired and how to renew. So the site does not always "vanish": it can be replaced by a renewal page that still loads.
3. If nobody renews and the registration is deleted, a 30-day Redemption Grace Period follows, during which the registry disables DNS resolution. Lookups now fail for everyone, typically with NXDOMAIN ("no such domain"), until the domain is restored.

Country domains such as .sk, .cz, .de or .uk follow their own registry's rules, so check the registrar's terms for each client's domain.

The practical point: step 2 can look like a working website to a check that only reads the status code.

A triage playbook

When a client says "the site is gone", run these before touching anything. Replace example.com with the client's domain.

See the path from the root servers to the answer, and where it breaks:

dig +trace example.com

Compare the nameservers the registry has with the ones you expect:

dig +short NS example.com
whois example.com | grep -iE "name ?server|nserver"

Check the expiry date (the field name varies by registry, and some country registries do not publish one):

whois example.com | grep -iE "expir"

Ask each authoritative nameserver for its SOA serial. Different serials mean a nameserver has not picked up the latest zone, or a change is still being copied:

for ns in $(dig +short NS example.com); do echo "$ns $(dig +short SOA example.com @$ns | awk '{print $3}')"; done

Compare a public resolver with the authoritative answer. If the authoritative server is right and the public resolver is not, you are waiting for a cache to expire, not looking at a wrong record:

dig +noall +answer example.com @1.1.1.1
dig +noall +answer example.com @<one of the NS names above>

Then fix at the right place: an expired domain at the registrar, wrong nameservers at the registrar, a wrong record at the DNS provider.

Before a migration: lower the TTL first

Resolvers keep an answer for as long as its TTL says. If the A record has a TTL of 86400 seconds (one day), some visitors can keep going to the old server for a day after you change it.

1. Check the current TTL on the authoritative server: dig +noall +answer example.com @<nameserver> (second column).
2. Lower it to 300 seconds at least one old TTL before the change, so for a one-day TTL, a day or two ahead.
3. Make the change, then confirm it on the authoritative server and on a public resolver.
4. Keep the old server running until the old TTL has passed.
5. Raise the TTL again once everything points to the new place.

What to monitor

• The expiry date of every client domain, with reminders that reach you, not only the client.
• The records that matter: the A (or AAAA) record of the site, and the MX record if the client's mail depends on it.
• The value of those records, not just that they exist, so a record pointing to the wrong server is caught.
• The page itself: during the renewal-page phase above, only a check that reads the page content notices the difference.

What Baromio's DNS monitor and domain alerts cover

• DNS monitor: looks up one record type (A, AAAA, MX, CNAME or TXT) for a hostname, through the normal resolver on Baromio's server, as often as your plan allows: every 5 minutes on Free, every minute on Pro, every 30 seconds on Business. It fails when no record comes back. With an Expected Value, it also fails when the first record in the answer does not contain that text, ignoring case, so google.com matches an MX record like aspmx.l.google.com. For a name with several A records the first one can vary, so leave the expected value empty there, or use a part all of them share.
• What the DNS monitor does not do: it checks from one server only, does not compare nameservers or SOA serials, and does not test propagation across resolvers. Use the playbook above for those.
• Domain expiry: switch on Monitor Domain Expiration on an HTTP or keyword monitor (it is off by default). Once a day Baromio reads the domain's expiry date from WHOIS and alerts you, by email and to your connected Slack, Discord or webhook channels, on the days when 30, 14 and 7 days remain. There is no alert after the 7-day one, so treat that as the last call. The monitor card shows a WHOIS badge with the days left. If the registry publishes no expiry date, no date appears. For domains under a two-part suffix such as .co.uk the lookup does not work yet; check those by hand.
• Plans: both are available on every plan; Free covers 20 monitors, Pro (9 EUR a month) 30 and Business (29 EUR a month) 100.

A checklist for each client

1. Write down the registrar, the DNS provider and who pays the renewal.
2. Make sure renewal reminders reach you, and that auto-renewal has a valid card.
3. Put a DNS monitor with an expected value on the site's main record, and one on MX if mail matters.
4. Switch on domain expiry alerts on the site's HTTP or keyword monitor.
5. Lower the TTL a day or two before any DNS change, and keep the old server up until the old TTL has passed.

Sources

• ICANN, Expired Registration Recovery Policy: reminder timing (2.1), interruption of the DNS resolution path and the renewal landing page after expiry (2.2), the 30-day Redemption Grace Period after deletion with DNS resolution disabled (3.1, 3.2).