How to Point a Domain to a Hosting Account: A DNS Step-by-Step
Learn to point a domain to your hosting: nameservers vs A records, the DNS step-by-step, propagation, and the most common mistakes.
You bought the domain, signed up for hosting, uploaded your site — and then you type the address into the browser only to get a blank page, a "server not found" error, or worse, the registrar's "parked domain" screen. The question hits immediately: I paid for everything, so why isn't the site showing up? The answer is almost always the same. The domain and the hosting both exist, but no one told one to look for the other. That "introduction" is DNS pointing, and it's the missing step between owning the pieces and having a live site.
This guide is about exactly that link: taking a domain that's already yours and making it serve the right hosting. It isn't about choosing or registering the domain — it's about connecting it.
What actually happens when someone types your domain
A domain and hosting are two separate things, often bought from companies that aren't even the same. The domain is the name (yoursite.com). The hosting is the computer (server) where your site files live, identified by an IP address, something like 203.0.113.45.
DNS (the Domain Name System) is the phone book that translates the name into the IP. When someone types your domain, the browser asks DNS: "what's the IP for yoursite.com?". If DNS answers with your hosting's IP, the site loads. If it answers with the registrar's IP (or nothing at all), you get the parked-domain page or an error.
Pointing the domain, then, is just writing the right answer into that phone book.
The two paths: nameservers or DNS records
There are two ways to point, and picking the wrong one is the source of half the confusion. You only need one of them.
Path 1 — Change the nameservers (most common and recommended). Instead of editing record by record, you hand the entire DNS zone over to the host. In the panel where the domain was registered, you replace the default nameservers with your host's, usually something like:
ns1.yourhost.com
ns2.yourhost.com
From then on, the host controls everything: site, email, subdomains. It's the ideal option when the host runs your whole site and you don't want to fuss with details.
Path 2 — Edit the A and CNAME records. Here you keep the current (registrar's) nameservers and just adjust individual records. The two key ones:
Type Name Value
A @ 203.0.113.45 ← root domain points to the hosting IP
CNAME www yoursite.com ← "www" follows the root
This path makes sense when you need fine control — for example, the site on one host but email on another service, or pointing just a subdomain (shop.yoursite.com) to a different platform.
The rule of thumb: if the host gives you nameservers, use Path 1. Only fall back to Path 2 when you have a specific reason to split services. And never mix the two expecting both to work at once — whoever holds authority is whoever the active nameservers point to.
Step by step
This flow works for Namecheap, Hostinger, GoDaddy, Cloudflare, or any registrar — only the menu names change, not the logic.
Get the details from the host first. Before touching the domain, go to the hosting panel (cPanel, hPanel, Plesk) and note either the two nameservers or the server's IP address. It's usually under "Account details" or in the welcome email.
Confirm the domain already exists on the host. Many people point DNS before "adding" the domain in the hosting panel. The result: DNS reaches the right server, but the server doesn't know which folder to serve and returns the host's default page. Register the domain (under "Domains" or "Add-on Domains") before or alongside pointing it.
Open the DNS zone at the registrar. In the panel where the domain was bought, look for "DNS", "Edit Zone", "Nameservers", or "DNS Servers".
Apply your chosen path. Swap the nameservers (Path 1) or edit the A and CNAME records (Path 2). Save.
Wait for propagation. The change isn't instant. DNS servers worldwide cache old answers for a period set by the TTL (Time To Live). It can take anywhere from a few minutes to 24–48 hours for everyone to see the new destination.
If you're still at the earlier stage — picking a registrar, deciding between .com and a country domain, understanding renewal costs — read the sibling guide on how to register a domain first, because pointing only makes sense once the name is actually yours.
The mistakes that break pointing most often
- Thinking it's broken during propagation. The number-one error is hitting refresh for 10 minutes and concluding it failed. Before changing anything, wait and test on another network (mobile data, say), because your own computer may have the old IP cached.
- Mixing nameservers and A records. If you changed the nameservers, editing A records in the registrar's panel does nothing — authority now belongs to the host. Edit the records there.
- Forgetting the
wwwrecord. The root (yoursite.com) works, butwww.yoursite.comerrors out because the CNAME is missing. Set up both. - Inherited sky-high TTL. If the old record had a TTL of 86400 (24h), the change drags. When you know a migration is coming, drop the TTL to 300 (5 min) a day in advance so the change propagates fast.
- Pointing to the wrong IP. Shared-server IPs are usually fixed, but always double-check the exact value in the panel — no stray spaces, no transposed digits.
How to confirm it worked
Don't trust the browser alone; it lies because of cache. Use the terminal:
# Shows the IP the domain is returning right now
nslookup yoursite.com
# Or, more detailed, with dig:
dig yoursite.com +short
If the returned IP matches your hosting's, the pointing is correct — the rest is just waiting for propagation to reach your machine. For the reverse — when you have an IP and want to know who owns it or which provider hosts it — use the IP address info tool to confirm that IP really is your server.
What to take from this guide
Pointing a domain is a single concept dressed up as a technical problem: making DNS answer with your hosting's IP instead of the registrar's. Decide between swapping nameservers (almost always the right call) or editing A/CNAME records (only with a reason), apply it on one side only, and give propagation its time. Once nslookup shows the right IP, the work is done — any blank screen after that is cache or hosting configuration, not DNS.
- 01 UTF-8 and encoding problems: why accents break and how to fix them What UTF-8 is, code points, mojibake, and why accented text turns to garbage — the mechanism explained end to end.
- 02 MIT, Apache, and GPL Licenses: Practical Differences for Developers MIT, Apache 2.0, and GPL are not the same thing. Understand permissive vs copyleft, patent protection, and compatibility before shipping code to production.