A website rests on two separate services: the domain, which is the site's name, and hosting, the server where files and databases live. Most people buy both in one place, which is convenient. Some companies, however, deliberately keep the domain with one provider and hosting with another. The approach has a clear logic, especially for a business whose site needs to live for many years.
The domain is an asset, hosting is replaceable
Customers remember a domain for years; it is printed on business cards, ads and email addresses. Hosting may change several times as the site grows, from shared hosting to a VPS and then a dedicated server. When the two are separate, switching hosts never touches the domain: you buy new hosting and update DNS records, without transfers, authorisation codes or ownership questions.
Ownership and access control
The biggest benefit is control. Agencies or freelancers sometimes register a client's domain and hosting under their own accounts, and when the relationship ends the client does not know who really owns the name. A domain held in the company's own account, registered to the company, stays yours regardless of where the site is hosted. Protect that account with a strong unique password and two-factor authentication where available, and tie it to an email address that does not live on the hosting server.
Where to manage DNS
You can point the domain's NS records to the hosting provider and manage everything there, or keep DNS with the domain provider and point A, MX and TXT records to the host manually. The second option makes switching faster because you change one A record instead of waiting for an NS change.
misol.uz. 3600 IN A 203.0.113.10
www.misol.uz. 3600 IN CNAME misol.uz.
misol.uz. 3600 IN MX 10 mail.misol.uz.
mail.misol.uz. 3600 IN A 203.0.113.10
misol.uz. 3600 IN TXT "v=spf1 a mx ~all"Check the current setup at any time with a few lookups:
dig +short NS misol.uz
dig +short A misol.uz
dig +short MX misol.uzThe NS answer tells you which provider is authoritative for the zone, and therefore where changes must be made. Editing records in a panel that is not authoritative is a common reason why "nothing changes". If your domain is at sayt.uz, both NS changes and manual DNS records are handled on the domain's page in the cabinet.
Switching hosts without downtime
- A day or two before, lower the A record TTL to around 300 seconds.
- Copy the site and database to the new host and test it.
- Test the new server before changing DNS, for example via your
hostsfile. - Switch the A record and keep both servers running for a few hours.
- Raise the TTL again and shut down the old hosting.
curl -I --resolve misol.uz:443:203.0.113.20 https://misol.uz/
dig +short A misol.uz @8.8.8.8Plan for the SSL certificate on the new server, which is usually issued once the domain points there, and migrate mailboxes and MX records separately if email lives on the hosting.
Example: a Tashkent logistics company
A logistics firm's site was run by a freelancer on his own hosting, with the domain in his account. When he moved on, the company could not update the site and renewal notices went to his inbox. After the domain was finally moved to the company, it adopted a rule: the domain stays in its own account with auto-renew on, while hosting is chosen with whoever maintains the site. Two years later, moving to a VPS meant changing a single A record, and customers noticed nothing.
The downsides
You deal with two accounts, two billing dates and two support teams. The classic mistake is letting one service expire: paid hosting is useless if the domain lapses. When something breaks, providers may point at each other, so someone on the team should understand DNS basics. For a small site this complexity may not be worth it, but for a business-critical site that will evolve, keeping the domain separately under your control pays off.