What Happens to Your Domain and DNS if the Host Controls Both
When your hosting provider registers the domain on your behalf, the name is very often held in the provider's own account with the registry, and you are listed only as a contact. You do not own the domain in any legal sense; you hold a contractual right to use it, and that right is only as strong as the provider's willingness to keep the record pointed at you. The practical question is not "who owns it" but "who can move it, and what do I need to move it myself".
That distinction matters because a domain controlled by a hosting provider usually means three separate things are bundled together: the registration itself, the authoritative name servers, and the DNS records. Each can be separated, and each has its own escape hatch.
What the registry actually stores about your domain
A domain registration is a row of data at a registry, mediated by a registrar. The registry does not know or care who runs your website. It knows a registrar, a set of name servers, and a status. The registrar knows the contacts, the auth code (also called the EPP code or transfer key), and the lock state. When a host registers a name for you, the registrar of record is typically the host or a reseller brand they operate, and your email address may be the only trace of you in the whole chain.
You can see part of this without any credentials, because registration data is public. The command is whois, and the shape of the output is stable even if the field names vary by registry:
$ whois example.com
Domain Name: EXAMPLE.COM
Registrar: SOME REGISTRAR, INC.
Name Server: NS1.PROVIDER.NET
Name Server: NS2.PROVIDER.NET
Domain Status: clientTransferProhibited
Registry Expiry Date: ...
The line to read first is Domain Status. If you see clientTransferProhibited, the registrar has locked the name against transfers. That lock is normal and often protective, but only the party with registrar access can lift it. If that party is your host and you have no login to the registrar, you cannot transfer the domain no matter what your invoice says. The second line to read is Registrar. If it does not match a company you have an account with, you are not the customer of record.
DNS is a separate layer from registration
Even when you can log in and edit DNS records, the registration and the zone are different systems. The registry delegates your domain to a set of name servers, and those name servers answer queries for the zone. If the host controls both, they control the delegation and the contents of the zone.
You can see the delegation with dig, asking the parent zone rather than a resolver cache:
$ dig +short NS example.com
ns1.provider.net.
ns2.provider.net.
$ dig +short A www.example.com
203.0.113.10
The first answer tells you where authority lives. If both name servers belong to the host, then moving to a new host means changing the delegation at the registrar, which brings you back to needing registrar access. The second answer shows the record itself. Note that a resolver may serve a cached answer, so add +trace or query the authoritative server directly when you need to be sure.
There is a subtler version of this problem. Some hosts let you edit records in a control panel, but the zone file they show you is generated from a template, and certain record types are managed for you. An MX record for mail, a CAA record restricting which certificate authorities may issue for the name, or a wildcard entry may be present without your knowledge. You can enumerate what is actually published, though a full zone transfer is usually refused:
$ dig +noall +answer example.com AXFR @ns1.provider.net
; Transfer failed.
A refused transfer is expected. It means you have to read records one type at a time, or get the zone from whoever runs it.
What to check before you depend on the name
Start by confirming who the registrar is and whether you have credentials there. If you do not, ask for them in writing, and ask that the registrant contact be changed to an address you control. The registrant contact is the one that receives transfer approval messages, so an address at the host's domain is a single point of failure.
Next, confirm the auth code exists and that you can retrieve it. Without it, an outgoing transfer cannot be initiated. Then check the lock state and confirm that you, not the host, can toggle it.
For DNS, decide deliberately whether you want the host to run your authoritative name servers at all. Many people point the delegation at a dedicated DNS provider and keep registration and hosting separate, so that changing hosts never touches the delegation. That is three vendors instead of one, but each can be replaced without disturbing the others. If you keep DNS with the host, at least export the zone regularly and store it somewhere you control.
Watch for the coupling that makes departure painful. A host that registers the name, runs the name servers, and holds the only login is three locks on the same door. Any one of them can be opened; all three together mean you are asking, not acting.
Leaving without losing the name
The transfer procedure is standard. Unlock the domain at the current registrar, obtain the auth code, and submit a transfer request at the new registrar. The new registrar contacts the registrant email for approval. Once approved, the registry moves the delegation and the new registrar becomes the registrar of record. The old name servers stop being authoritative when the new registrar publishes its own, so plan the DNS cutover before you start, not after.
If the host refuses to cooperate, the escalation path runs through the registrar and then the registry, and ultimately through the dispute process defined by ICANN policy for your top level domain. That process is slow and requires evidence that you are the registrant. Keep the invoice, the welcome email, and any correspondence that names you as the customer.
What to do next: pull a whois for each domain you care about and write down the registrar and the status flags. For any name where the registrar is not an account you can log into, send a written request for registrar access and registrant contact changes today, and keep the reply. Then move your DNS delegation to a provider you control independently, so that the next time you change hosts, the only thing that changes is an A record.
