I took my own domain down this week. Moved nameservers before the zone existed
at the other end, so for about twenty minutes elfadili.com delegated to a
server that disclaimed it. Mail queued at the senders and nothing was lost, but
that was luck and a retry window, not judgment.
The outage was the cheap part. It announced itself. Every resolver returned nothing, the failure was total and obvious, and it was fixed in the time it took to paste nine DNS records.
The expensive part was what I found on the way there.
A 200 on a page that says Coming Soon
elfadili.com had been serving a placeholder for months. Four kilobytes,
default template, the word "Soon."
That would be fine, except my company site published the domain as a profile
link, and shipped it inside the structured data as the canonical url for me as
a person. So the site whose entire argument is that it publishes receipts was
telling search engines that its founder's canonical home was an empty page.
Nothing errored. The domain resolved. TLS was valid, the certificate had months
left, and the server returned HTTP 200.
A 200 is the correct response for successfully serving a placeholder. The protocol was working exactly as designed. It just wasn't answering the question I cared about, which was not "does this URL respond" but "does this URL contain anything."
Two DMARC records and no DMARC
While auditing the zone I found two _dmarc TXT records. One said
p=quarantine. The other said p=none and pointed its reports at a vendor I
stopped using.
Both were syntactically valid. Both started with v=DMARC1. Any tool asking
"does this domain have DMARC" would say yes, twice.
RFC 7489 says that when a domain publishes more than one DMARC record, receivers ignore the policy entirely. Not "pick the strictest." Not "use the first." Ignore it.
So I had spent whatever effort I spent configuring DMARC, had two records proving I had done the work, and had no DMARC at all. Probably for years. The check that would have caught it is not "is there a DMARC record" but "is there exactly one."
Ready, and every route a 404
Then I did it to myself in real time.
I deployed the new site into a Vercel project I had created a week earlier by
pushing a folder of static HTML. Creating it that way set the framework preset
to "Other" with an output directory of public, and that setting is sticky. It
does not re-detect.
So the build compiled. The deployment reported Ready. Its own preview URL returned 200. And every route on the live domain returned 404, including the homepage, because the platform was serving a framework application as a directory of files.
Three separate signals said the deploy succeeded. It did succeed. Building and uploading is what "deploy" means, and all of that happened. Nobody was going to tell me the artifact was being served wrong, because from the platform's point of view it wasn't.
The shape of it
These are three unrelated systems, and I want to be careful not to draw a grander lesson than three data points support. But they failed the same way.
In each case I had a check. In each case the check passed. In each case it was answering a nearby question that I had quietly accepted as a proxy for the one that mattered.
- Does the domain respond, instead of does the page have content
- Is DMARC configured, instead of is DMARC in effect
- Did the deploy succeed, instead of does the site render
The proxy is always cheaper to measure. That is why it wins. "Does this return 200" is one request. "Does this page contain what I think it contains" means deciding what you think it contains, which is work, and the answer goes stale every time the content changes.
I do not think the fix is more monitoring. More checks of the same shape produce more green, which is the problem. The fix is narrower and more annoying: for the few things that would genuinely hurt if they were quietly wrong, check the property you actually care about, and check it against the real thing rather than against a description of it.
Not "does DNS resolve" but "send yourself an email and confirm it arrives." Not "did the build pass" but "fetch the live URL and read what comes back." Both of those are slower. Both of them would have caught two of the three above on the day they broke rather than months later.
The last one I would have caught anyway, about ninety seconds after I took the site down.