How do I find out who hosts my DNS?

Look up the NS (nameserver) records for your domain — that's the authoritative answer to 'who answers DNS queries for me.' The hostnames give the provider away: ns1.cloudflare.com means Cloudflare is serving your zone, ns-cloud-a1.googledomains.com means Google, ns.cafe24.com means Cafe24, and so on. You don't need any login to see this; a public DNS lookup reads it off the parent TLD servers. If the NS hostnames belong to your registrar, your registrar is also your DNS host; if they belong to someone else, that's where your records actually live.

What's the difference between my registrar and my nameservers?

Your registrar is who you bought the domain from and who can transfer or renew it — that's ownership. Your nameservers are the servers that answer DNS questions about the domain — that's hosting. They're often the same company by default, but the moment you point your domain at an external DNS provider (Cloudflare, Route 53, a web host), the registrar still owns the name while someone else answers for it. RDAP/WHOIS shows the registrar; an NS lookup shows the nameservers. Confusing the two is why people edit records in the wrong place.

I edited a DNS record in my registrar's panel and nothing changed. Why?

Almost always because the registrar is no longer your authoritative DNS host. If you (or someone before you) switched the domain's nameservers to an external provider, the registrar's DNS panel still shows editable records — but nothing on the internet reads them anymore, because resolvers follow the delegation to the external nameservers instead. The records you changed just sit there, ignored. Find the real nameservers first, then edit at that provider. The registrar panel is only authoritative if the NS records still point back to the registrar.

Find Your Domain's Nameservers and DNS Provider

Problem

You need to change a DNS record — add a TXT to verify a domain, point an A record at a new server, fix an MX for mail — and you’ve hit the question nobody tells you the answer to: where do I actually do this? You log into the registrar where you bought the domain, find a DNS section, make the change, and… nothing happens. Or you’re not even sure the registrar is the right place. Somebody set this up years ago, maybe you, maybe a developer who’s long gone, and the domain works fine, which means some server somewhere is answering for it. You just don’t know which one, or how to get into it.

This is one of the most common ways people get stuck, and it comes from conflating three different things that happen to live near each other.

Three layers, and only one of them edits records

A domain name has three separate jobs, usually handled by one or two companies, and the whole confusion comes from treating them as one thing:

The registrar — who owns the name. This is who you bought the domain from and who bills you to renew it. The registrar controls the domain record at the registry: expiry, transfers, and crucially, which nameservers the domain is delegated to. The registrar is ownership, not necessarily DNS.
The nameservers — who answers for the domain. These are the authoritative DNS servers that respond when the world asks “what’s the A record for this domain?” The list of them is the delegation, and it’s stored one level up in the TLD’s zone. This is the layer that matters for “where do I edit records,” because records only count if they’re served by the nameservers the delegation points to.
The DNS records — the actual answers. A, AAAA, CNAME, MX, TXT. These live inside the zone on the nameservers. Edit them anywhere else and you’re writing to a file nobody reads.

The registrar and the nameservers are the same company by default — buy a domain at a host and it points at that host’s nameservers out of the box. But the instant anyone delegates the domain elsewhere (the most common case: moving DNS to Cloudflare for the free tier and speed), ownership stays at the registrar and answering moves to the new provider. After that, the registrar’s DNS panel is a decoy.

Find the authoritative nameservers

Stop guessing from memory and read the two authoritative sources directly. Neither needs a password, because this information is public by design.

The NS records tell you who hosts your DNS. Look up the nameserver records for the domain. You’ll get hostnames like ns1.example-dns.com and ns2.example-dns.com, and the hostname is the provider’s name badge. A few you’ll see constantly:
- *.cloudflare.com → Cloudflare
- ns-cloud-*.googledomains.com → Google Cloud DNS
- *.awsdns-*.net/.org/.com/.co.uk → Amazon Route 53
- *.azure-dns.com/.net → Azure DNS
- *.domaincontrol.com → GoDaddy
- ns.cafe24.com, ns.gabia.co.kr, *.dnszi.com → common Korean hosts
Whatever those hostnames belong to is where your records actually live, and where you log in to change them.
RDAP (or WHOIS) tells you the registrar. The structured registry record shows the sponsoring registrar — who you renew with and who can change the delegation — and usually the registered nameservers too. If you’ve lost track of where you even bought the domain, this is how you find it.

Read together: the registrar is where you change which nameservers answer; the nameservers are where you change the records. For an ordinary record edit, you want the second one.

Why “I changed it and nothing happened”

The classic trap is editing records at a place that isn’t authoritative, and the two usual shapes are:

Records edited at the registrar after DNS was moved elsewhere. The registrar keeps a DNS editor in its panel whether or not it’s actually serving your zone. If the NS records point at Cloudflare, the registrar’s A record is a dead letter — real, saved, and completely ignored. The tell is simple: the nameservers in the delegation don’t match the panel you’re editing in.
The reverse — nameservers set to a provider you never set up a zone at. Someone changed the NS at the registrar to point at a DNS provider, but no zone (or an empty one) exists there, so the authoritative servers answer with nothing or NXDOMAIN. Here the delegation is “correct” but the records are missing at the destination.

Either way, the fix starts the same: find the authoritative nameservers, confirm that’s where you’re logged in, and edit there. If you want to consolidate — move DNS back to the registrar, or over to a single provider — that’s a nameserver change at the registrar, and it then takes time to take effect (that’s a different problem; see below).

Diagnose with DechoNet

DNS Lookup reads your domain’s NS records straight off the authoritative chain, so you can see exactly which nameserver hostnames are in the delegation — and therefore which provider hosts your DNS and where to log in to edit records.
RDAP / WHOIS shows the sponsoring registrar and the registered nameservers at the registry level — the answer to “who do I renew with” and “who can change the delegation,” independent of any panel you may be looking at.
Propagation Check confirms that the nameservers you found are actually what resolvers around the world are using, so you don’t act on a mid-flight delegation that’s still changing.

Verification Checklist

Run a DNS Lookup for your domain’s NS records and read the nameserver hostnames — those name your DNS provider.
Match the provider in those hostnames to a login you have. That provider’s DNS panel — not the registrar’s, unless they’re the same — is where records are edited.
Use RDAP to confirm the registrar (for renewals and for changing the delegation) and that the registered nameservers match what the lookup shows.
Before editing, confirm the panel you’re in belongs to the nameservers in the delegation. If they don’t match, you’re in the wrong place.
If a record you changed isn’t taking effect, re-check the delegation first — editing a non-authoritative panel is the most common cause.

When to Escalate

If the NS records point at a provider you have no account for, the domain was set up by someone else. Chase access to that provider — the registrar can’t edit records it isn’t serving. The registrar can, however, repoint the nameservers to one you control.
If you’ve just moved nameservers and are waiting for the switch to apply, that’s a timing question, not a lookup one — see Nameserver Change: How to Check It Took Effect.
If you’re on a Korean host and connecting a domain for the first time, the provider-specific three-layer walkthrough in Cafe24 domain not connecting uses the same registrar / nameserver / record framing with that panel’s fields.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.