Verifying a Domain by Reading DNS Breaks for Everyone Behind a Proxy

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

You add your domain to a platform. It tells you to create a CNAME. You create it, traffic starts flowing, the site loads — and the platform still says "CNAME not detected".

Nothing is wrong with your DNS. The platform is checking the wrong thing.

If a service verifies your custom domain by resolving your record and looking for itself in the answer, it will fail for every domain behind a proxy — including domains that are configured perfectly and already reaching it. The fix, for anyone building this, is to stop reading DNS and prove the thing you actually care about: that requests for the name arrive.

Why the lookup fails on a working domain

Put Cloudflare's proxy in front of a record and the public answer for that name is Cloudflare's own addresses. The CNAME you created still exists — it is what Cloudflare consults internally — but it is not what the world is told, and it is not visible to an outside resolver at all.

So a verifier that resolves app.example.com and looks for its own hostname finds addresses belonging to a company that is not it, and concludes the customer has not done the work. The customer has done the work; traffic is already arriving. This is not a rare edge — a large share of real domains sit behind a proxy, and disproportionately the ones run by people who know what they are doing.

Prove the request, not the record

The property worth proving was never "a record exists somewhere with our name in it". It is "requests for this hostname reach us" — which is the actual precondition for serving the domain, and the only one that matters operationally.

That is provable in a way no proxy can interfere with, because forwarding requests is a proxy's entire job. Publish a token at a fixed path on the hostname — say /.well-known/your-platform-challenge — then fetch it back over the public internet. If it comes back, requests for that name land on your infrastructure, and nothing else can produce that answer.

A proxy forwards it. A CDN forwards it. A redirect is followed. There is no configuration a customer can hold correctly that this check calls wrong.

Three properties this buys you, all of them free

It survives every DNS arrangement. CNAME, A record, ALIAS, ANAME, a flattened CNAME on a root domain — the platform never has to know which the customer used, or care when they change it.

It needs no second record. No TXT, no separate verification hostname, no instruction the customer follows once and then has to remember not to delete. And it is unambiguous where a DNS read is not: a request either arrives or it does not.

It points at one environment, deliberately. A name proved this way is proved against whatever is actually serving it, which is the moment to be sure that is production and not the environment you test in.

The one thing to get right while building it

Until a hostname is proved, it must expose nothing. The route that answers the challenge should serve the token and have no application behind it at all.

Otherwise you have built a way for somebody to claim a name they do not own and have your platform serve their content on it, before any check has run. Until it is verified, the challenge route is the only thing that name may reach.

The second is a race worth naming rather than discovering: claiming is first-come, so somebody can reserve a hostname they do not own and have it verify later if the real owner ever points it at you. The industry answer — Vercel's and Netlify's both — is to demand a TXT record only for a contested hostname, so the ordinary customer never meets one. Write that down as a known limit; stating what a tool cannot do is the same discipline.

Test it yourself, against any platform

Before you file a support ticket about a domain that "will not verify", find out what your hostname is actually serving. Save this as domain-reach.sh:

#!/bin/sh
# usage: ./domain-reach.sh app.example.com
H="$1"

echo "== what the world resolves =="
dig +short "$H"

echo
echo "== what actually answers, over both schemes =="
for scheme in https http; do
  printf '%s: ' "$scheme"
  curl -sS -o /dev/null -w 'HTTP %{http_code}  server=%{scheme}  redirects=%{num_redirects}\n' \
       -L --max-time 10 "$scheme://$H" || echo "no answer"
done

echo
echo "== is the challenge path reachable? (path varies by platform) =="
curl -sS -o /dev/null -w 'HTTP %{http_code}\n' --max-time 10 \
     -L "https://$H/.well-known/" || echo "no answer"

How to read it. If dig returns addresses that are not your platform's but curl gets a real response from your application, you are proxied and your setup is fine — a verifier saying otherwise is reading DNS. No answer on either scheme means the name genuinely reaches nothing yet, and no verification method would pass. HTTPS failing while HTTP succeeds means the certificate has not been issued; that usually settles within minutes of traffic arriving, and is worth waiting out before changing anything.

FAQ

Why does my custom domain say "CNAME not detected" when the site loads? Because the platform is resolving your record and your proxy is answering with its own addresses instead of the CNAME underneath. The domain works; the check does not. Nothing you change in DNS will fix it — the platform has to verify differently.

Can I just turn the proxy off to verify? Usually yes, and it is the standard workaround: disable the proxy, verify, turn it back on. That it works is not a defence of the design — it means the platform made you undo a correct configuration to satisfy a check that should not have needed it.

Is proving by request less secure than a TXT record? No, and arguably more. A TXT record proves you control DNS at some moment; a returned token proves requests for the name arrive at the platform right now, which is the condition under which it will serve the name. On aidrop.it that is the whole proof — the hostname answers with a token and nothing else until it is verified.

Does this work with Cloudflare's proxy on? Yes, on or off. Cloudflare forwards the request to the origin, so the token comes back either way. That is precisely why the check is a request rather than a lookup.

What if two people claim the same hostname? The first claim holds it, and the second is refused. Closing the remaining gap — someone claiming a name they do not own — needs proof at claim time, which is where a TXT record earns its place, for contested hostnames only.

Cover: https://commons.wikimedia.org/wiki/File:Female_Indian_telephone_switchboard_operator_-_%22Helen_of_Many_Glacier_Hotel.%22,_26_June_1925_LCCN2014718418.jpg by Bain News Service, Public domain, via Wikimedia Commons. Cropped to 16:9 within the original frame. Alt text: A telephone switchboard operator connecting calls by hand at a plugboard in 1925.