Who Controls Your Domain? How to Find Its Registrar and DNS Host

Find the registrar with ICANN Lookup, identify authoritative nameservers, and locate the account that can change the right DNS records.

FBFenwei BianAuthorOct 30, 2026est. 6 min read
  • domains
  • dns
  • guide

To find your domain registrar, start with ICANN Lookup. To find your DNS host, inspect the domain's authoritative nameservers. Those checks answer different questions. A registrar manages a registration, while an authoritative DNS service answers queries about the domain. ICANN describes registration lookup, and Cloudflare describes authoritative nameservers.

If your immediate task involves an MX, TXT, or website address record, locate the active DNS account before editing. A familiar registrar dashboard can contain an inactive DNS zone. Changing that inactive zone will not change answers from another provider's authoritative service.

This guide helps a domain administrator identify the correct provider and account. The examples use reserved example domains and documentation addresses. The commands illustrate a workflow and do not report a live lookup.

The registration record identifies the registrar

Open ICANN Lookup and enter the registered domain. Remove the protocol, page path, query, and email prefix. For the hypothetical URL https://shop.example.com/orders, begin with example.com. Keep shop.example.com in your notes for the later website investigation.

Find the registrar entry in the result. Record the registrar name, any identifier the result displays, and the lookup time. ICANN's browser client retrieves registration data through RDAP. The tool provides a public route to registration information, rather than access to your private registrar account. ICANN documents the client.

Use the registrar entry to identify where registration administration belongs. Then compare the result with purchase receipts, renewal notices, and your organization's account inventory. A reseller relationship can require additional account investigation. Treat your own billing records as account evidence, and treat the public lookup as registration evidence.

Do not enter account credentials into an unfamiliar website found through a search advertisement. As practical account advice, use the provider's verified website and your existing account records. Ask the organization that purchased the domain to confirm who holds administrative access.

The registrar, DNS provider, and web host serve different roles, and a proxy can obscure the origin.

Authoritative nameservers identify the active DNS service

Query the domain's NS records. On a machine with nslookup, use nslookup -type=NS example.com.. The final dot makes the DNS name explicit. Microsoft documents the query tool and its record-type options. The command reference explains the syntax.

Nameserver hostnames often suggest a provider. Treat the suggestion as a lead. Cloudflare supports standard and custom nameservers, so a branded hostname alone cannot establish the organization behind every service. Cloudflare describes its nameserver options.

Confirm the provider through an account that lists the domain and its assigned nameservers. Compare those assigned names with the public answer. If the account shows different names, investigate whether the account contains an inactive zone, an incomplete migration, or the wrong domain.

Also consider subdomain delegation. A team can delegate a subdomain to separate authoritative servers. The authority for example.com does not automatically identify the account managing every delegated name beneath example.com. DNS divides authority through zones and referrals. RFC 1034 explains delegation.

For a delegated application, check the name relevant to that application. Ask the DNS administrator whether a child zone exists before adding records to the parent zone. This practical check prevents a parent-zone edit from becoming an unexplained no-op.

Use Namefi's DNS lookup with the domain and the NS record type to record a public resolver's nameserver answer. Compare the names with the provider and account records. This check does not identify the registrar account or independently confirm the website's origin host.

Authority and policy records control separate decisions.

The website address does not establish the registration provider

A website address lookup serves another purpose. An A or AAAA result identifies an address returned for the queried name. The result does not identify the registrar account.

A reverse proxy also changes the meaning of the returned address. Cloudflare states that a proxied record returns Cloudflare addresses rather than the origin address. DNS-only records expose the configured origin address instead. Cloudflare explains proxy status.

Therefore, avoid concluding that the operator of a returned network address also holds your registration or stores your website files. Record the observation precisely: “This lookup returned an address associated with a proxy.” That statement leaves the origin-hosting question open.

The domain and hosting guide explains the service boundaries. The public registration data guide explains additional limits of provider inference.

The intended change determines which account matters

Use the following routing table as practical administrative guidance. Confirm each provider's requirements before making a production change.

Intended changeAccount to identify firstEvidence to retain
Renew the registrationRegistrar or purchasing reseller accountRegistration record and renewal receipt
Change the authoritative serviceRegistrar account and destination DNS accountAssigned nameservers and a complete zone inventory
Add an email verification TXT recordActive authoritative DNS accountRequired owner name and exact TXT value
Point a website to a hostActive authoritative DNS account and hosting accountRequired records and host configuration
Change application filesHosting or application deployment accountDeployment project and hostname mapping

Before changing nameservers, inventory the current zone. Include mail routing, verification records, and delegated subdomains. As editorial operational advice, arrange a rollback plan and a responsible administrator. A website-only checklist can miss email dependencies.

Use the DNS record guide to classify existing records. Save a copy of the old configuration through your provider's supported export or documentation process. Keep private verification tokens in the authorized system rather than a public support ticket.

A controlled change preserves records and tests dependencies.

A provider handoff needs a small evidence packet

When access remains unclear, send the internal administrator the exact domain, registrar entry, nameserver answer, lookup time, and intended change. Include the account name if your organization already knows the account. Exclude passwords, recovery codes, and payment details.

Ask the administrator to confirm control of the relevant account. Public data can identify a service boundary, but public data cannot demonstrate that a particular colleague can edit the zone. Keep that distinction explicit in the handoff.

Your next action should match the question. Use ICANN Lookup for registration, an NS query for DNS authority, and the hosting dashboard for application deployment. Once the correct account is confirmed, make the smallest authorized change and verify the exact record afterward.

Example names use reserved documentation domains.

Sources and further reading

ICANN explains its registration lookup

ICANN: Information for RDAP Users. Checked 2026-10-30.

Cloudflare explains authoritative nameservers

Cloudflare: Nameservers. Checked 2026-10-30.

Microsoft defines the query tool

Microsoft Learn: nslookup. Checked 2026-10-30.

RFC 1034 explains zone delegation

RFC 1034: Domain Names — Concepts and Facilities. Checked 2026-10-30.

Cloudflare separates proxy addresses from origin addresses

Cloudflare: Proxy status. Checked 2026-10-30.

RFC 2606 reserves example domain names

RFC 2606: Reserved Example Domains. Checked 2026-10-30.

About the author(s)

Software Developer & Writer • Namefi
FBAuthor

Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.

She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.

For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.

Related guides

Discuss this post

View the discussion on Namefi Discuss