Domain, Hosting, and DNS: What Each One Actually Does

Domain, hosting, and DNS in one request

Domain, hosting, and DNS are often sold together, but they are separate layers. The domain is the registered name, hosting serves the pages and application, and DNS publishes the records that point the name toward the right website, email, or verification service. Each layer can be operated by a different company and can fail independently.

When someone visits, the browser asks DNS where the hostname points and then requests the page from that destination. Email follows separate DNS records to a mail service. That separation is why a website move can break email even when nobody meant to move it.

Know what domain registration controls

ICANN describes a registrant as the holder of the registration agreement with a registrar. Registration provides control of a name for a renewable term; it does not store a site, create mailboxes, or guarantee that the name points anywhere useful. The registrar account controls renewal, transfer, contact details, and the nameservers that identify who answers DNS queries.

Keep the registrant contact current and monitored, record the renewal date, protect the registrar login with a unique password and multi-factor authentication, and keep the transfer lock enabled between deliberate transfers. If an employee, agency, or former developer owns the account, correct that before an urgent change is required.

Understand what hosting supplies

Hosting provides the computing, storage, and network service that return HTML, images, styles, scripts, and application data. A hosted builder bundles this layer into its subscription. A self-hosted CMS normally requires a separate host, and email may be another service again.

Evaluate hosting by the workload it can support, the provider's documented support boundary, the backup and restore path, reliability, and the operating work left to the owner. None of those choices requires the domain to be registered with the same company.

Use DNS records as routing instructions

DNS records tell other systems where a hostname's services live. A and AAAA records point toward IPv4 and IPv6 addresses. A CNAME points one hostname at another name. MX records route email. TXT records commonly support ownership verification and email authentication. Nameserver settings at the registrar determine which DNS provider is authoritative.

A record's time to live controls how long a resolver may cache an answer, so a change is not immediately visible everywhere. The bare domain, `www`, `mail`, and other subdomains also have independent records. Document the complete zone rather than assuming one working hostname proves that every service is configured.

Make DNS and hosting changes in a safe sequence

Export or record every existing DNS entry before changing anything. Confirm the registrar, authoritative nameservers, host, mail provider, account owners, and recovery routes. Prepare and test the destination first, lower the relevant TTLs in advance when appropriate, and change one layer at a time so a failure has a small set of possible causes.

Do not replace an entire record set just because a new host supplied two website records. Preserve mail and verification records unless those services are deliberately moving. Verify the site, certificate, redirects, forms, and email from outside the administrator's normal network, then retain the dated before-and-after record sets.

• Prepare the new destination and a rollback before pointing traffic.
• Move the website without changing MX records when email is staying put.
• Avoid changing registrar, nameservers, hosting, and mail in one window.
• Restore ordinary TTL values after the change is stable.

Isolate common failures by layer

If the name does not resolve, check the registration status, nameservers, and authoritative zone. If it resolves to the wrong page, inspect the A, AAAA, or CNAME value and the host configuration. If only `www` or the bare domain works, the other hostname may be missing a record or redirect.

If the site works but mail stops, compare MX and TXT records with the saved zone. If only some people see the old destination, cached answers may still be within their TTL. Diagnose the first wrong layer before making another change; stacking guesses can turn a small error into a longer outage.

Keep a domain and DNS ownership register

Record the registrar, registrant, renewal date, billing owner, recovery contacts, nameservers, DNS editor, hosting provider, mail provider, and people with access. Store a dated DNS export somewhere outside the DNS account. Review the list at launch, after personnel changes, and at least annually.

The domain is the address that links, email, and customer memory depend on. Treat its account and renewal as a business continuity asset, while keeping hosting and email replaceable through clear records and tested change procedures.