What actually happens after you type a domain name and press Enter? The browser does not look for “the website” as one object. It needs an address, a route to that address, a machine or service that can answer, and a protocol for requesting the page. Domain names, DNS, hosting, and HTTP cooperate, but they are not interchangeable names for the same thing.
A useful mental model is a journey with four stops: the domain is the human-readable identity, DNS translates that identity into routing information, hosting provides a place for the application or files to run, and HTTP carries requests and responses between the browser and a server.
Stop one: the domain gives the visitor a name
Suppose you register `example.dev`. A domain name is an address people can remember and use online; it is not automatically a folder containing your HTML. ICANN’s beginner material describes domain names as part of how people find an online presence and explains why the naming system can feel mysterious at first in its guide to domain names.
The name has labels separated by dots. In `blog.example.dev`, `dev` is the top-level domain, `example` is the registered domain label, and `blog` is a subdomain label. The subdomain can point to a different service from the root domain. That does not mean the browser has found a server yet; it has only been given a name to resolve.
| Part | Example | Role |
|---|---|---|
| Protocol | https | Defines how the browser communicates securely. |
| Host | blog.example.dev | Names the destination being requested. |
| Path | /guides/start | Identifies a resource at that host. |
| Query | ?mode=dark | Provides optional request parameters. |
Stop two: DNS asks which destination owns the name
DNS, the Domain Name System, is the lookup layer between a name and routing information. When a browser needs `blog.example.dev`, a resolver asks DNS-related infrastructure for records that describe where or how the name should resolve. Cloudflare’s documentation explains that DNS records contain information about a domain, and that different record types serve different purposes in its DNS records reference.
A common A record associates a name with an IPv4 address. A CNAME can point one hostname at another hostname. MX records describe mail delivery. TXT records can prove ownership or carry policy information. The record does not contain your entire website. It supplies an instruction used to reach the next system.
Type Name Content
A @ 203.0.113.10
CNAME www example.dev
TXT @ "verification=value"DNS answers can be cached. A TTL tells resolvers how long a record may remain cached before asking again. That is why changing a DNS record does not guarantee that every visitor sees the new destination immediately. Different recursive resolvers and devices may hold the previous answer for different periods.
The small experiment
When a domain appears to be “down,” inspect the layers separately. First ask whether the name resolves. Then ask whether the resolved destination accepts a connection. Finally ask whether the application returns the resource you expected.
nslookup example.dev
curl -I https://example.dev/The first command investigates name resolution. The second sends an HTTP request and shows a response header. A DNS answer with a failing HTTP response is not the same failure as a missing DNS record.
Stop three: hosting gives the project somewhere to run
Hosting is the service or infrastructure that serves your site’s files, runs its application, or connects requests to a backend. A static site may be deployed as HTML, CSS, JavaScript, and images on a storage-backed platform. A dynamic site may require a runtime, database, background process, and configuration. “Hosting” describes the place and service that makes those resources available; it does not describe the domain name visitors type.
| Hosting model | What you manage | Good learning fit |
|---|---|---|
| Static hosting | Build output and deployment settings. | Portfolio, documentation, landing page. |
| Shared hosting | Application files within a provider’s managed environment. | Simple CMS or small server-rendered site. |
| Virtual server | Operating system, runtime, security updates, and deployment. | Learning server administration deliberately. |
| Managed platform | Application configuration, build command, and environment variables. | Deploying without managing every machine detail. |
| Container platform | Image, runtime contract, networking, and service configuration. | Projects that need reproducible environments. |
The right choice depends on the project’s behavior. A static page does not need a database just because a more complex application might. Conversely, a server that stores user accounts needs more than a folder of public files.
Our guide to how websites work provides the broader browser-to-server picture. The important connection here is that hosting is one participant in the chain, not the name of the whole chain.
Stop four: HTTP carries the request
After the browser resolves a destination and opens a connection, it sends an HTTP request. MDN describes HTTP as a client-server protocol: the browser sends a request, and the server returns a response containing a status, headers, and sometimes a body in its HTTP overview.
GET /guides/start HTTP/1.1
Host: example.dev
Accept: text/htmlA response might look like this:
HTTP/1.1 200 OK
Content-Type: text/html
<!doctype html>
<html>...</html>The server may be one physical machine, a set of load-balanced instances, a cache, or an application that generates the response on demand. HTTP does not require the visitor to know which one. Its job is to define the message exchange.
| Symptom | Likely layer to investigate first | Useful evidence |
|---|---|---|
| “Server not found” | DNS or network | Resolver result and domain records. |
| DNS points to the old provider | DNS cache or record configuration | Record type, value, and TTL. |
| Connection refused | Hosting or service process | Port, service status, provider logs. |
| HTTP 404 | Application route or file path | Request URL and server route. |
| HTTP 500 | Server-side application | Response body and server logs. |
| Page loads without styles | Asset paths, build, or cache | Network requests for CSS and JavaScript. |
Why people buy a domain and hosting separately
A domain registrar manages the right to use the name. A hosting provider serves the application or files. One company may sell both services, but the roles remain distinct. Keeping the distinction visible makes migrations easier: you can move the site to a new host while retaining the domain, or change DNS while leaving the application code untouched.
The connection is usually made by changing nameservers or DNS records. That configuration is powerful enough to break email, verification, subdomains, or production traffic if a record is removed casually. Treat DNS as configuration with dependencies, not as a cosmetic settings page.
Free hosting is a learning choice, not a moral category
Free platforms can be excellent for a first project. They may provide a subdomain, limited build minutes, sleep behavior, or restrictions on databases and custom domains. Those constraints become part of the learning experience because they reveal what the application actually needs.
Outgrowing free hosting is not measured only by traffic. You may need a background worker, persistent storage, custom networking, private environment variables, predictable build times, or a service-level guarantee. Choose based on requirements you can state, not on the prestige of a provider.
The complete journey in one trace
- The visitor enters `https://blog.example.dev/guides/start`.
- The browser uses DNS resolution to find routing information for `blog.example.dev`.
- The browser connects to the resolved destination over the appropriate transport and security layers.
- The browser sends an HTTP request for `/guides/start`.
- A proxy, cache, or server receives the request and returns a response.
- The browser parses the HTML and requests CSS, JavaScript, images, and other resources.
- The page may make later requests for API data or navigation.
Each step can succeed while the next one fails. That is why debugging starts by naming the layer instead of saying “the hosting is broken.”
Questions that clear up the vocabulary
Is a domain name the same as an IP address?
No. A domain is a human-readable name. DNS records can map that name to an IP address or another hostname, but the domain and address are different objects.
Does buying a domain create a website?
No. Buying or registering a domain gives you control over a name. You still need hosting or another service that can answer requests for that name.
Why can a DNS change take time?
Resolvers and devices cache DNS answers for the period permitted by the record’s TTL. During that period, different visitors may use different cached destinations.
Can hosting and a domain come from the same company?
Yes. A provider can sell both, but the domain registration, DNS configuration, and hosting service still perform different jobs.
Keep the layers visible
A domain helps people name a destination. DNS helps systems find it. Hosting supplies the application or files. HTTP carries the conversation. Once those roles are separate in your mind, error messages become evidence instead of a wall of mysterious infrastructure terms.
Trace what the browser does with the response →
When a migration changes only one layer
Imagine moving `example.dev` from one hosting provider to another. The application may already be copied and healthy at a temporary hostname, but visitors still reach the old host because DNS has not changed. Or DNS may point to the new host while the new server is missing an environment variable. The migration is not complete until the name, route, service, response, and important assets agree.
Make a small change log: old DNS values, new DNS values, expected TTL behavior, verification commands, and a rollback plan. Then test the root domain, `www`, important subdomains, email records, HTTPS, and one real page. The HTTP and HTTPS guide explains why the secure protocol is another layer of the same journey, not a replacement for DNS or hosting.
This checklist also helps when support says “the server is up.” A running server can still answer the wrong hostname, serve an old build, return a missing route, or fail only when the application requests its database. Ask for the exact URL, status code, response body, and deployment revision instead of accepting a layer-free description of the incident.
Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.