---
title: "Why Our Cloudflare Verify Tool Never Queried Public DNS for www"
canonical: https://dxdev.com/blog/verification-tool-layered-systems/
datePublished: 2026-06-12
---
A customer told us their site was down at 3:57 PM on June 12th. We had migrated their domain to Cloudflare four days earlier and marked it done.

Our [migration verify tool had signed off](/everyday-ai/the-check-that-only-asks-itself/) on it. Green check, moved on. But `www` was still pointing at the apex, and the apex bounced through a relay to a dead address. Anyone hitting the bare domain got the site. Anyone hitting `www` got nothing.

## What the DNS check was actually asking

The verify tool's DNS check pinned `www` to the Cloudflare edge before testing it. That detail decided everything. The tool checked what Cloudflare's edge returned when asked directly, with Cloudflare doing the DNS resolution. It never checked what the internet resolved for that hostname.

If you migrate `www` correctly, those two answers agree and the check is fine. If you don't, the pinned check still hits Cloudflare's edge. Cloudflare still answers for the hostname, because it's a proxied custom hostname in the zone, and the tool reports success. The public DNS record for `www` was never queried. The tool was testing the edge's opinion of the domain.

The check was correct for the question it asked, and the question was the wrong one. "Does Cloudflare correctly serve this hostname" and "does the public internet correctly resolve this hostname to Cloudflare" are different tests. Only the second one is what a customer experiences.

## Four domains, then the sweep

Four domains had `www` still aimed at the apex instead of the Cloudflare-facing CNAME target. We repointed all four inside the hour.

Fixing four domains doesn't tell you whether there's a fifth. So the next step was a full sweep of every one of our Cloudflare custom hostnames, checked against live public DNS resolution. Re-running the existing verify tool would only have re-confirmed its own answer faster, so the sweep used actual DNS lookups against public resolvers. It ran through a verifier subagent so the check itself could be re-run and cross-confirmed instead of resting on a single pass. Zero other domains came back broken. Four was the whole blast radius.

## The same bug wrong in the other direction

Two related bugs surfaced in the same window, and they compound the same failure from opposite sides.

The first was the CFStatus badge computing "partial" for domains where `www` sits on Cloudflare but there's no apex custom hostname, even when the apex was correctly steady-state on our relay. That flagged a large share of the correctly migrated domains as "[Awaiting DNS](/blog/dns-verification-cache-staleness-trap/)" when they weren't. The customer's domain was the tool being wrong in the optimistic direction, reporting success on something broken. The badge was wrong in the pessimistic direction. Both had one root cause: the status logic inferred migration state from what Cloudflare's config said should be true, and never looked at what DNS resolution actually returned.

## What changed in the tool

One fix patched the verify step to check live `www` and apex DNS resolution directly, using pinned curls against the actual public answer instead of the edge-scoped one. A wrong `www` can't pass verification now, because the check no longer asks Cloudflare to grade its own homework.

The other fix handles the inverse. When the lifecycle scan proves the apex is provably on the relay (`apex_provenance_ok`), the badge upgrades to "migrated" and stops sitting on a stale "partial" heuristic.

A verification tool that queries the system it's verifying, through that system's own resolution path, will confirm that system's beliefs about itself. It can't see the gap between "Cloudflare thinks this hostname is proxied correctly" and "a customer's browser gets an IP address that answers." When the test and the target share an execution path, a failure in that shared path is invisible to both. Here the tool signed off on a domain whose `www` was broken, and only a customer report surfaced it. The check that would have caught it leaves the layer it's validating and asks an independent one, such as live public DNS lookups.