Connecting a Domain to Hosting: Nameserver or A Record — Which Should You Choose?

You've bought the domain, you've got the hosting — but the site still won't come up

You've uploaded the site to the new hosting, opened the control panel, and you're waiting to see the site when you type in the domain address. But the browser shows a DNS_PROBE_FINISHED_NXDOMAIN error, or it opens the old white page from the previous hosting. This is the moment you need to decide which method to use to connect the domain to the hosting: changing the nameserver or adding an A record. A wrong choice means hours of wasted time and, in the worst case, several hours of downtime for users waiting on the site.

The difference between these two methods is simple, but the consequences are not. A nameserver means you hand over all DNS management of the domain to the hosting servers. An A record means you just add one line to the current DNS and keep everything else under your own control. Which one is right? It depends on how much you use your current DNS.

Method one: Changing nameservers — when you want everything in one place

In your hosting panel, usually in the "Accounts" or "Domains" section, you'll be given two server names such as ns1.servernet.cloud and ns2.servernet.cloud. You enter these two names in the domain registrar's panel (where you bought the domain) under the Nameservers section. After saving, it takes between 2 and 48 hours for this change to propagate across the internet. This period is called DNS propagation.

The advantage of this method? Everything is managed from one panel. MX records for email, TXT records for SPF and DKIM, and CNAME records for subdomains are all created right where you manage the hosting. If you work with cPanel, adding a domain and creating email under "Email Deliverability" automatically adds the necessary records. For someone who is just starting out or has only one site, this method has the fewest errors.

But it has a cost: if you have multiple domains with different services and manage their DNS centrally, changing the nameserver means losing that centralization. For example, if your domain is connected to Cloudflare and you use its firewall and CDN, changing the nameserver to the hosting takes Cloudflare out of the loop. This is where people make mistakes: many realize after changing the nameserver that their email isn't working. Why? Because the domain's MX records were defined in the previous DNS, and the new DNS doesn't have them. The site comes up, but email bounces back with a "connection timed out" error.

Method two: Adding an A record — when you like your current DNS

In this method, the domain's DNS is left untouched. You only add an A record to the current DNS panel that points the domain name to the new hosting IP. You get the IP from the hosting panel — it's usually listed under "Server Information" or "IP Address." The record looks like this:

example.com.  3600  IN  A  185.10.10.10
www.example.com.  3600  IN  A  185.10.10.10

The number 3600 is the TTL, or Time To Live — the amount of time other DNS servers cache this response. If you set the TTL to 300 (five minutes) before making the change, the site will come up much faster on all devices after the switch. This is a detail few people pay attention to, and they regret it later.

The advantage of this method? Your current DNS remains untouched. Email you have on another service like Google Workspace or Zoho keeps working without any changes. If you use Cloudflare or a similar DNS service, you've only changed the destination IP, and all the security settings stay in place. For sites that have organizational email and moving email isn't part of the plan, the A record is the safer choice.

When an A record won't work

If your hosting uses a shared IP — which is common with shared hosting — multiple domains may be on one IP. In this case, the web server needs to know which domain to serve for which site. This is done with ServerName in Apache or server_name in Nginx. If you haven't added the domain to the hosting panel as an Addon Domain or Parked Domain, the A record will go to the hosting's default page, not your site. So the order matters: first add the domain in the hosting panel, then add the A record.

Testing the connection before launch: the hosts file and dig

DNS propagation takes between 2 and 48 hours. Waiting to see the result is a waste of time. The way around it is to simulate the connection on your own system before propagation. The hosts file is located at /etc/hosts on Linux and macOS, and at C:\Windows\System32\drivers\etc\hosts on Windows. Add a line to it:

185.10.10.10  example.com  www.example.com

Now open the browser and enter the domain. If the site comes up with the new content, everything is correct and you just need to wait for DNS propagation. If it gives an error, the problem isn't DNS — it's the hosting settings or the site code. This simple test resolves the "is it DNS or is it hosting?" confusion once and for all.

To check how DNS is actually propagating, use the dig command:

dig example.com A +short
dig example.com NS +short

The first output should show the new hosting IP. The second output should show the nameserver names that the domain is delegated to. If the first output still shows the old IP, either the TTL hasn't expired yet or you've entered the record incorrectly. There are also online DNS checking tools that test from various points around the world; but dig on your own system is sufficient for an initial test.

Which method should you choose?

If your domain is newly purchased and no other service is connected to its DNS, choose the nameserver. It's simpler and everything is managed from the hosting panel. If the domain is old, you have organizational email on another service, or you use a CDN, choose the A record. This method preserves the current DNS and only changes the site's destination.

There's also a third scenario: connect the domain with the nameserver, and later if you want to move to Cloudflare, just change the nameserver to Cloudflare and build the records there. This path is also common and perfectly fine; just remember to copy the MX and TXT records from the previous DNS during this migration. Forgetting these records is the most common cause of email downtime after a migration.

For sites on Linux hosting, the IP and nameserver names are usually visible on the first page of the panel. If you bought the domain elsewhere and don't know where the registrar's panel is, check the domain purchase email; the DNS management link is right there.

After connecting: what to check

The connection is established and the site is up. It's not over yet. Make sure to check three things:

• MX records: If email is on this same hosting, check in the hosting panel that MX records have been created. The command dig example.com MX should show the mail server. If the output is empty, your email won't work.
• SPF and DKIM records: These are to keep your emails from being marked as spam. In cPanel, they're usually created under Email Deliverability. Without them, your emails will end up in the spam folder.
• SSL certificate: After connecting the domain, activate the SSL certificate. If you use Let's Encrypt, there's a button in the hosting panel for automatic issuance. Without SSL, browsers show security warnings and users will be afraid to enter your site.

If you've moved the site to a new domain, read the guide on changing a site's domain without losing SEO before doing anything. 301 redirects and updating internal links are tasks you need to do after the DNS connection, and if you don't plan for them now, you'll lose your old traffic.

Still having issues? Here's where people go wrong

The most common mistake I've seen: a user adds the A record but uses www instead of @. That means only www.example.com points to the new IP, and example.com without www still goes to the old site. Or vice versa. When you test, check both. The second most common mistake: they set the TTL to 86400 (one day) and then wait up to 24 hours to see the result after the change. If you know the IP is going to change, set the TTL to 300 at least 24 hours in advance.

The third mistake is when the user thinks DNS is the problem, but it's actually browser cache. After changing DNS, refresh the browser with Ctrl+Shift+R (or Cmd+Shift+R on Mac). If you test in incognito mode, you'll also bypass the browser cache. These three issues account for 90% of "connecting domain to hosting" problems.

Frequently asked questions

How long does connecting a domain to hosting take?

DNS propagation usually takes between 2 and 48 hours. By setting the TTL to 300 before the change, this time is reduced to a few minutes. For an immediate test, use the hosts file to verify the connection before propagation.

Should I change the nameserver or add an A record?

If the domain is newly purchased and no other service is connected to its DNS, change the nameserver. If you have organizational email on another service or use a CDN, add an A record so the current DNS remains untouched.

After changing the nameserver, my email isn't working — why?

The domain's MX records were defined in the previous DNS, and the new DNS doesn't have them. Create the MX, SPF, and DKIM records in the new hosting panel. You can check the status with the command dig example.com MX.

How do I know DNS has propagated correctly?

Use the command dig example.com A +short. If the output shows the new hosting IP, propagation is complete. Online DNS checking tools also test from various points around the world and give a more accurate picture.