Domain vs hosting

What it means

A domain registration gives you the right to use a name under the applicable registration agreement; hosting supplies the environment that serves the website. DNS connects names to services, and mail hosting is another responsibility. One company can sell all four, but buying, renewing or moving one service does not automatically perform the other jobs. A domain can be registered before a website exists, and a platform can publish a site under its own hostname without you registering a custom domain. Registrant resources · Publishing choices

Try it

Example — change one responsibility at a time. Begin with a custom domain connected to host A. Renew the domain and inspect the unchanged hosting and mail rows. Prepare host B: the site is now ready there, but the web destination still points to A. Only the separate web-record action points it to B. Undo steps through local changes; Reset restores the entire starting arrangement.

Choose domain-only or platform-hostname to test different starting points. Provider grouping changes the commercial arrangement, not the technical roles. The no-JavaScript example begins with an active registration, a prepared host A and web DNS directed to A; host B has not been prepared. The scene neither sends DNS changes nor simulates cache timing.

Four responsibilities worth separating

The familiar “address versus building” analogy helps at first, but DNS is not one immutable address label. A zone can contain different records for the web, mail and other services. A hostname can point to an alias instead of directly to an IP address. A single name can also have both A and AAAA records. The specific record and its dependencies matter more than the analogy. DNS data model · Record formats

What renewal actually changes

In the lab, renewal changes only the registration row. It does not make a missing deployment appear, copy a database, change the authoritative web destination or extend an unrelated hosting subscription. That is a deliberate separation of actions, not a simulation of a registrar's billing system.

For a real domain, establish the registrant account, renewal arrangement, contact and recovery access using the applicable registrar and registry rules. Do not infer a universal grace period or deletion date from an unrelated TLD's documentation. A receipt for hosting is not proof that the registration is active, and control of a hosting dashboard is not necessarily control of the registrant account. ICANN registrant resources

Preparing a host is not pointing DNS

Imagine moving a documentation site from host A to host B. Preparing B means publishing a complete candidate and configuring B to recognize the intended hostname. HTTPS also needs to work for that hostname. In the lab, the single Prepare action represents all of those prerequisites; on a real service they are separate checks, not a magic button.

At this point A can still be the authoritative web destination. That is useful: preparation and verification can happen before traffic is redirected. Conversely, changing DNS before B is ready can direct visitors to an empty deployment or incorrectly configured endpoint. DNS carries a destination; it does not provision the application there. Routing records to resources

The example intentionally treats B's files as separately prepared, not transferred by the DNS action. A dynamic site may need a data-migration and write-consistency plan as well. This comparison does not perform that migration or provide a zero-downtime guarantee. For a real record update, follow the separate bounded procedure for changing DNS safely.

Keep mail out of a website-only move

The model holds its MX and mail-related TXT data unchanged throughout a web move. That demonstrates the intended boundary: a website destination change is not a mailbox migration. In production, review mail dependencies rather than assuming the separation is automatic. For example, the host named by an MX record may itself depend on an address record you are considering changing. Mail-exchanger and address records

Save existing mail-routing and authentication records before any wider DNS change. Do not remove MX, SPF, DKIM or DMARC data merely because the new web host does not mention email in its setup screen. Also preserve other unrelated records. A provider's “replace zone” or nameserver migration is broader than changing one web RRset; this lab does not authorize it.

A single bill can obscure these boundaries. Cancelling a bundle may affect several services even though the DNS action you intended was narrow. Check the actual contract and account dependencies before cancelling the old provider. This is an operational precaution, not a claim that every bundle behaves alike.

In practice

Create a four-row ownership record before connecting or moving a site. For each role, record the provider, account owner and authorized person who can recover access. Store secrets in the appropriate secure system, not in a public worksheet or an educational widget. Verify which DNS service is currently authoritative rather than editing a dormant zone that happens to be visible in an account.

Then describe the change in one sentence: “Prepare host B and change the web destination; retain registration and mail.” If the actual provider workflow also changes nameservers, email products or account ownership, stop and revise the scope. A different dashboard label does not make those extra changes incidental.

After a real move, verify the public hostname, HTTPS and representative routes, then check unaffected services. The lab's immediate state transitions omit recursive caches and deployment timing; real users may temporarily reach different destinations. Keep a recoverable previous deployment according to the migration plan rather than deleting it as soon as one test works.

Same company or separate companies?

There is no universal winner. A bundle may make some account tasks easier, while separate providers may make responsibilities more explicit. Evaluate the particular integration, access model, renewal terms, export capability and recovery process. The number of companies does not by itself establish reliability or security.

The useful distinction is action versus consequence: renewal maintains registration; preparation makes another deployment ready; a web DNS change redirects that part of name resolution. None is a substitute for the others. A successful move keeps the intended boundary visible and verifies the services that should not have changed.