What is a domain name? DNS mapping explained

A domain name is the readable address people type to reach a website, while DNS is the lookup system that maps that name to hosting, email, or another service. Buying the name is only half the job; the records decide where visitors actually land.

Domain name, DNS, and hosting are different jobs

Start with the split. The domain is the name, DNS is the routing table, and hosting is the machine or platform serving the site. Keep those jobs separate in your head, and launch-day problems get much easier to diagnose.

A registrar sells or manages the domain registration. A DNS provider stores records such as A, CNAME, MX, TXT, and NS. A host, builder, or deployment platform serves the website files or application behind the name.

That separation matters when you move a site. You can keep the same domain at Namecheap, run DNS at AWS or Cloud, and point the site at Vercel without changing the public address.

How a domain maps to your site

When a visitor enters a domain, the browser asks DNS which service should answer. DNS checks the domain’s nameservers, finds the zone, and returns the relevant record. The browser then connects to the returned destination.

The record type decides what happens:

• A record: points a name to an IPv4 address for a server or load balancer.
• AAAA record: points a name to an IPv6 address.
• CNAME record: aliases one name to another managed hostname.
• MX record: routes email for the domain.
• TXT record: stores verification, SPF, DKIM, DMARC, and other control data.
• NS record: declares which nameservers are authoritative for the zone.

Here is the trap. DNS is not ownership. A domain can be registered correctly and still send visitors nowhere useful if the nameservers, A record, CNAME, or TLS setup is wrong.

What the registrar actually controls

The registrar controls the registration relationship: ownership contact, renewal, transfer lock, authorization code, and nameserver delegation. It may also offer DNS, email, privacy, and hosting, but those are separate services.

For a small site, bundling registration and DNS is convenient. For a business site, separating registrar access from DNS access is often cleaner. It reduces the chance that a hosting cancellation or account lock also breaks domain recovery.

Here is the practical split:

Do not treat a free domain bundle as the asset. The asset is control of the registered name, the renewal path, and the recovery channel. Read the renewal line before you call the bundle cheap.

Where the real cost appears

Domain pricing is not just the checkout number. Registration, renewal, privacy, premium TLDs, DNS hosting, email, and recovery can sit in different line items. The first year can be the least useful year for budgeting.

HostScout data currently shows a narrow slice of registrar and DNS lines:

Read those numbers as comparison inputs, not a universal domain budget. A TLD can price differently by registry, region, renewal period, and promo. DNS can also add query-based cost when traffic grows.

Cheap hosting has a second invoice. Domains can, too. The quiet line items are usually renewal, privacy, email, DNS add-ons, and recovery work after someone loses access to the account.

When to keep everything together

Keeping domain, DNS, hosting, and email in one account is fine for a brochure site, test project, or personal page. It is simpler to configure, and the support team can see the whole stack.

Choose the bundled path when:

• The site is low risk: downtime is annoying, not business-critical.
• The team is small: one login and one bill reduce operational friction.
• The records are simple: web and email need only common defaults.
• The exit plan is clear: you know how to export DNS and transfer the domain.

Avoid the bundle when the domain is tied to revenue, legal identity, paid ads, or customer email. In those cases, the domain account deserves separate recovery and stricter access control.

When to separate registrar, DNS, and hosting

Separation is worth the extra setup when the domain is business-critical. The goal is not architecture purity. The goal is to make migration, recovery, and provider disputes less destructive.

Use a separate DNS provider when you need fast rollback, multiple hosting targets, strict audit control, or high-traffic routing. Use a separate registrar account when the domain should survive a hosting vendor change.

The clean operating rule: the registrar should be boring, the DNS provider should be easy to roll back, and the host should be replaceable without losing the name.

Common mistakes that make a domain look broken

Most domain problems are not mysterious. They are usually one bad assumption in the chain between registration, DNS, hosting, and browser cache.

The usual suspects are:

• Wrong nameservers: the registrar points to an old DNS provider.
• Mixed www behavior: the bare domain works but www does not, or the reverse.
• Missing email records: the website works, but MX, SPF, DKIM, or DMARC was lost during migration.
• Stale DNS cache: a correct change appears broken until old records expire.
• TLS mismatch: the host serves a certificate for the wrong name.

Before blaming the registrar, check which nameservers are authoritative. Before blaming the host, check whether DNS points to that host at all. It is boring work, which is exactly why it catches expensive mistakes.

Freshness and method

HostScout separates glossary explanation from volatile commercial data. Definitions and DNS mechanics are stable, while provider prices, plan labels, and DNS service lines are refreshed from current provider data before publication review.

The article uses public HostScout provider records for the price table and keeps external source details out of the body. That keeps the reader focused on the decision: who controls the name, who routes it, and what can break during a move.