Free tools
DNS provider detector
Type a domain and see which DNS host serves it, which connect path a custom-domain setup would take there, and whether that host has onboarded one-click Domain Connect templates. The same engine DoDomain runs for every customer domain, read from the zone's own nameservers.
How nameserver detection works
There is no registry of "who hosts this domain". The one authoritative signal is the delegation: the parent zone publishes NS records naming the nameservers that serve the domain, and whoever operates those nameservers is the DNS provider, whatever the registrar's billing page says. Detection is therefore a DNS question, answered in three steps.
First, find the zone that owns the name. Records for api.eu.acme.com do not necessarily live in acme.com: a zone ends where a delegation begins, so if eu.acme.com carries its own NS records, that is the zone, that is the provider, and that is the dashboard a user has to open. The detector walks down from the registrable domain looking for the nearest delegation cut and reports what it found, which is why the zone it names is sometimes shorter or longer than the string you typed.
Second, read that zone's NS records and match them. Providers run nameservers under their own names, and those names are stable in a way marketing pages are not. The match is a pattern over the nameserver hostname, and the hostnames themselves are printed in the result so you can confirm it rather than trust it.
Third, when no pattern matches, ask the zone. Domain Connect defines a _domainconnect TXT record through which a DNS provider publishes the address of its own settings endpoint. Fetching that endpoint returns the provider's identifier and the URLs a template apply would use, so a provider nobody has hard-coded can still identify itself, and a one-click path can exist for it. This is also the step that can time out, which the result reports as a fact about our request rather than a verdict on the provider.
What a provider's nameservers look like
A sample of the shapes you will see, with the path DoDomain routes to when it finds them. The engine's table is longer than this, and anything it does not recognise falls through to Domain Connect discovery and then to guided setup; an unknown provider is never a dead end.
| DNS host | Nameservers look like | Path DoDomain routes to |
|---|---|---|
| Cloudflare | *.ns.cloudflare.com | One-click via Cloudflare OAuth |
| GoDaddy | *.domaincontrol.com | Domain Connect: one-click only if it serves our templates |
| IONOS | *.ui-dns.com / .de / .org / .biz | Domain Connect: one-click only if it serves our templates |
| Vercel | ns1.vercel-dns.com | Domain Connect: one-click only if it serves our templates |
| WordPress.com | *.wordpress.com | Domain Connect: one-click only if it serves our templates |
| NameSilo | *.namesilo.com | Domain Connect: one-click only if it serves our templates |
| Namecheap | *.registrar-servers.com | Guided manual records |
| AWS Route 53 | ns-*.awsdns-*.com / .net / .org / .co.uk | Guided manual records |
| Squarespace | *.googledomains.com | Guided manual records |
| DigitalOcean | ns1.digitalocean.com | Guided manual records |
"Domain Connect" describes the protocol the provider speaks, not a promise of one-click: an apply is only offered once that provider has onboarded the specific template being applied, and a provider that has onboarded none of them gets guided setup. That is the question the template matrix in the result answers, and it is why an unprobed row says so instead of guessing.
Why the detected provider changes the setup
The DNS host is not trivia: it decides how much work a customer has to do, and that is the number that decides how many of them finish. The three paths, in descending order of how little the customer has to understand:
| Path | How the records get written | What the customer does |
|---|---|---|
| Tier 1: OAuth | The user grants DoDomain access to their own Cloudflare account, and the records are written through Cloudflare's API. | Approve a consent screen. No record is ever typed. |
| Tier 2: Domain Connect | An open protocol: DoDomain sends the user to their DNS provider with a signed template describing the records, and the provider writes them. | Approve a screen at their own DNS host. Available only where that host has onboarded the template. |
| Tier 3: Guided manual | DoDomain shows the exact records with provider-specific instructions and then verifies them against the zone's authoritative nameservers. | Copy two or three values into their DNS dashboard. Works everywhere, including hosts nobody has ever integrated with. |
Every path ends the same way. A provider's apply callback is never taken as proof: DoDomain reads the zone's authoritative nameservers and calls the connection verified only when the expected values are actually there. The connect-flow guide walks through what that looks like end to end.
Registrar, nameservers, records: three different things
The most expensive misunderstanding in custom-domain support is the assumption that the company a domain was bought from is the company serving its DNS. The registrar holds the registration. The nameservers, which the owner can repoint at any time, decide who answers queries. The records live in the zone on those nameservers. A domain registered at one company and delegated to another is completely normal, and a customer following the registrar's instructions will be editing a zone nobody is reading.
This matters when a customer is about to move. Changing nameservers moves every record at once, and the delegation at the registry carries a TTL you cannot lower: two days for .com, .net and .uk, and between 15 minutes and a day for the other top-level domains we measured. So the old nameservers must keep serving the old records until it expires. The propagation checker is the instrument for that window: it shows the authoritative answer and the cached one side by side, which is exactly the distinction a nameserver change makes visible.
The glossary entry on registrar vs DNS host explains delegation from the start, including how to check it by hand.
What this check does not tell you
It does not read existing records at the names a setup would write, it does not check CAA, SPF or DMARC (the SPF checker does that), it does not say whether the provider flattens a CNAME at the apex domain (the apex-domain guide is where that is recorded, provider by provider), and it does not say whether the domain is registered or resolving. It does not name the registrar, because the registrar is not visible in the DNS it reads. It answers one question (who serves this zone, and what can be done there) and stops.
Frequently asked questions
How does the detector know which DNS provider a domain uses?
It resolves the zone's authoritative NS records, the nameservers the registry delegates the domain to, and matches them against known provider nameserver patterns (Cloudflare, GoDaddy, Namecheap, Google Domains/Squarespace, Route 53, Vercel and others). When no pattern matches, it asks the zone's _domainconnect TXT record, through which a Domain Connect provider names itself. The nameservers are shown so you can check the match yourself.
What does one-click DNS setup mean here?
Two mechanisms let a product write DNS records for a user without the user editing records by hand: Cloudflare OAuth, where the user grants access once and records are written through Cloudflare's API, and Domain Connect, an open protocol where the user approves a template at their DNS host. The detector reports which of the two applies, or that the domain takes the guided manual path. Speaking Domain Connect is not enough on its own: one-click exists only where the provider has enabled DoDomain's templates, which the result checks template by template; a provider that has enabled none of them gets guided setup.
Why does a template row say not probed instead of yes or no?
Because we did not ask. A template is only probed when the domain takes the Domain Connect path and its provider published a discovery record; when the provider is too slow to answer, that is reported as a fact about our request, not about the provider. A red mark next to something we never measured would be a claim about someone else's product that we invented.
Is the result cached?
No. Every check is a live lookup against the zone's authoritative nameservers and, for Domain Connect zones, a live request to the provider's API. Change your nameservers and re-run the check to see the new answer.
Is the DNS provider the same as the registrar?
Often, but not reliably, and the difference is the single most common reason a customer edits records in the wrong dashboard. The registrar is who the domain was bought from; the DNS provider is whoever the nameservers point at, which the owner can change at any time. A domain registered at GoDaddy whose nameservers are Cloudflare's is served by Cloudflare, and GoDaddy's DNS screen will not affect it. This tool reports the nameservers, which is the authoritative answer to that question; it does not report the registrar.
Why does the tool name a zone that is not the domain I typed?
Because records are owned by the nearest DNS zone above the name, and a subdomain can be delegated to different nameservers than its parent. If eu.acme.com has its own NS records, a name beneath it is served there and not by acme.com's provider, so that is the zone the detector reports, and the one whose dashboard has to be opened.
Can I check a domain I do not own?
Yes. Every signal it reads is published in public DNS: the delegation, the nameservers, and the provider's own _domainconnect discovery record. Nothing here requires access to the domain, and nothing about its contents is revealed.
Start on the free plan
No card, no sales call: create an app, mint a session, and watch the first domain verify.
More free tools
- DNS propagation checker
One record, read from the authoritative nameservers and three public resolvers.
- SPF record checker
Parse a domain's SPF, walk its includes, count the lookups against the limit of ten.