How to Point a Domain at Your Server (DNS Guide)

Quick answer
Two cases: same provider for domain and hosting means add an A record; different providers means change your nameservers first.
The bare domain (example.com) takes an A record to an IP. Subdomains (www) take a CNAME to a name. A CNAME is never valid at the apex.
Lower the TTL before you change anything, or your cutover is a coin flip.
Verify with dig @1.1.1.1 example.com — never with a browser, which caches.

What do you need before you start?

Three things, and confirming all three up front avoids most of the failure modes described below.

Your server’s public IP address. For a VPS, this is the address in your provider’s control panel or the output of curl ifconfig.me run on the server. For a PaaS platform like Vercel, Netlify, Render, or Fly.io, the platform gives you a target hostname or IP to point at instead — check their “add custom domain” instructions, which usually tell you exactly which record to create.

Which provider hosts your DNS. If you bought the domain at one company and want records at another, you change nameservers. If both are the same, you edit records directly. This distinction is the first thing to establish, and it is the most common source of confusion.

Whether anything is already using the domain. Email is the usual culprit: changing nameservers or NS records can break mail routing if the previous provider hosted your MX records. If you use a hosted email service, note the MX and SPF records before you change anything.

How do I point a domain at a server?

The steps are the same everywhere; only the interface differs.

Step 1 — find your server’s public IP.

# Run this ON the server
curl ifconfig.me
# or
curl -4 ifconfig.me

For a PaaS platform, use the target hostname the platform gives you rather than an IP.

Step 2 — lower the TTL on any existing record. In your DNS panel, find the record you are about to change and set its TTL to 300 (5 minutes). Then wait for that to propagate — commonly an hour, occasionally longer. Skipping this step is the single most common cause of a botched migration.

Step 3 — choose your case.

Case A: domain and hosting at the same provider. Add or edit records directly in the provider’s DNS panel. This is the common case when you bought the domain from the same place you will host the site.

Case B: domain and hosting at different providers. Change the nameservers at your registrar to the two nameservers your DNS host gave you. You then manage all records at the DNS host, and the registrar becomes only a billing and renewal layer. This is what you need for Cloudflare, and for any provider that manages DNS for you.

Step 4 — create the records. For a VPS, the two records below are the complete minimum:

Type	Host	Value	TTL
A	`@`	`203.0.113.10`	`300`
CNAME	`www`	`example.com`	`300`

@ is how DNS panels denote the bare domain. This configuration makes example.com and www.example.com both resolve to your server.

Step 5 — verify from outside your own network.

# Query a public resolver directly, not your ISP's
dig @1.1.1.1 example.com A

# Confirm the www alias resolves too
dig @1.1.1.1 www.example.com

# Confirm the whole delegation is right
dig @1.1.1.1 example.com NS

You want to see your IP in the ANSWER SECTION. If you do not, keep reading — the next section is about why.

Step 6 — redirect one form to the other. Now that both resolve, make one canonical so you do not split traffic or duplicate content. In nginx:

server {
    listen 80;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Step 7 — get a certificate and raise the TTL. Add HTTPS once DNS resolves — see How to Add HTTPS to a Static Site. Then raise the TTL back to 3600 or higher so resolvers can cache properly and your queries are faster.

Why is my domain not working?

Work through these in order, cheapest first. Most of the time it is number one or two.

The record is on the wrong DNS host. If you edited records at your registrar but your nameservers point somewhere else, your changes have no effect at all — the authoritative servers do not live there. Check with dig NS example.com and confirm the nameservers listed are the provider you edited.

The TTL has not expired. Resolvers are still returning the old answer. This is normal, not broken. dig against a resolver you have never used gives you a fresher picture, and waiting is usually the correct fix.

You are testing in a browser. Browsers cache DNS aggressively and a normal reload does not clear it. This makes a working configuration look broken. Use dig, or test in a private window on a different network.

The server is not listening. DNS now resolves correctly and you have a 502, a connection refused, or a timeout. The name resolves but nothing answers — check the service, the port, and the bind address. A server bound to 127.0.0.1 is unreachable from the internet. See What Is a 502 Bad Gateway?.

A firewall is blocking the ports. Many VPS providers ship with a firewall allowing only SSH. Port 80 and 443 need to be open.

# Check from outside
nc -zv example.com 80
nc -zv example.com 443

The domain is pointed at the wrong thing. An old A record still exists alongside the new one, and the resolver is picking either. List all records for the name and remove what is no longer needed.

How do I point a domain at a PaaS platform or a CDN?

The shape is the same but the target changes.

PaaS platforms (Vercel, Netlify, Render, Fly.io) generally want a CNAME to a platform hostname, or an A record to a platform IP, depending on the platform. Add a custom domain in the platform’s dashboard first — it will tell you the exact record, and it usually also handles certificate issuance automatically once DNS verifies. Do not guess the target; read what the platform gives you.

Cloudflare and similar proxies work by nameserver delegation. You change the nameservers at your registrar to Cloudflare’s, and Cloudflare then manages all your records. Your origin’s address is entered at Cloudflare as an A record for the root and usually a CNAME for www.

Using a CDN? Point the domain at the CDN, not the origin. The CDN terminates the connection and fetches from your origin — see What Is a CDN and Do You Need One?.

Where this bites vibecoders
The specific way this bites vibecoders is skipping verification and trusting the platform’s green checkmark. A platform reports the domain as “verified” while the record points somewhere that will be overwritten later, or a second DNS provider still holds an older record with a longer TTL. The habit worth building is the one-command check — dig @1.1.1.1 example.com — run before and after every DNS change, so you are reading the real answer rather than a dashboard’s interpretation of it.

Where AI coding assistants get this wrong

Suggesting a CNAME at the apex, which is invalid and will be rejected or ignored.
Telling you to add an A record when you need nameservers (or the reverse) for a CDN-managed setup.
Not mentioning the TTL, so the migration works for you immediately and for nobody else.
Forgetting the firewall, so DNS resolves and every request times out.
Leaving both example.com and www serving 200, splitting canonical signals and analytics between two URLs.
No IPv6 record, making the site unreachable for IPv6-only visitors.
Pointing the domain at a PaaS platform’s IP by guessing, rather than using the value the platform provided.
Skipping the dig verification and declaring success based on the deploy output.

Checklist

Identify your server’s public IP, or the target hostname your platform gave you.
Establish which provider holds your DNS, and which holds the domain.
Lower the TTL to 300 and wait for that to propagate before changing anything.
Add an A record for @ pointing at the IP, with TTL 300.
Add a CNAME for www pointing at the bare domain.
If using Cloudflare or a similar proxy, change nameservers at the registrar instead.
Verify with dig @1.1.1.1 example.com A — not a browser.
Check dig NS example.com to confirm the authoritative nameservers are the ones you edited.
Open ports 80 and 443 in the server firewall.
Confirm the server is listening on 0.0.0.0, not 127.0.0.1.
Redirect www to the apex (or the reverse) so one URL is canonical.
Add HTTPS, then raise the TTL back to 3600 or higher.
Note your existing MX records before changing nameservers, so email survives.

FAQ

How do I point a domain at a VPS?

Find your server’s public IP address, then at your DNS host add an A record for the bare domain pointing at that IP, and a CNAME for www pointing at the bare domain. If you bought the domain somewhere other than where you host DNS, change the nameservers at your registrar to your DNS host’s nameservers first. Verify with dig.

Do I use an A record or a CNAME?

Use an A record for the bare domain (example.com) pointing at an IP address, because a CNAME is not allowed at the apex. Use a CNAME for subdomains like www or api, pointing at a name rather than an IP. Most providers will let you enter a CNAME at www pointing to example.com and redirect one form to the other.

Why is my domain not resolving after I set the record?

Usually one of four things: the record is on the wrong DNS host, the TTL has not expired yet so resolvers are still returning the old answer, you are testing from a browser with a cached result, or the record is correct but the server is not listening on port 80 or 443. Check each in that order with dig before touching the server.

Should I point my domain at a CDN or the origin server?

At a CDN or proxy if you use one, and at the origin if you do not. Cloudflare and similar services expect the domain’s DNS to point at them, and they then route to your origin — which usually means changing nameservers rather than an A record. Pointing at the origin directly is simpler but gives up the CDN’s caching and TLS benefits.

How long does DNS propagation take?

Minutes for most people, but the record is not fully propagated until every resolver’s cache expires, which is bounded by the TTL. With a 5-minute TTL most resolvers update within the hour; with a default 24-hour TTL you can wait nearly a day. That is why lowering the TTL before a planned change matters more than waiting afterwards.

Does changing nameservers break my email?

It can. If the old nameserver host held your MX records, or your SPF and DKIM TXT records, moving nameservers to a provider that does not have them configured means mail to your domain starts bouncing and your outgoing mail starts failing spam checks. Export those records first and recreate them, or use a DNS host that imports your existing zone.