How to Point a Domain to Cloud Hosting: DNS Records, Nameservers, and Troubleshooting

Overview

Your domain registration and your web hosting are separate services. The registrar manages the domain name, while the hosting platform stores and serves the website. DNS connects the two by telling browsers where to look for the site.

There are two common ways to connect a domain and hosting:

• Change nameservers: You delegate DNS management to the hosting provider. The host supplies nameserver addresses, and DNS records are then managed in the hosting control panel.
• Keep the registrar’s DNS: You leave nameservers unchanged and add or edit individual records, usually an A record for the root domain and a CNAME record for www.

Nameserver changes are convenient when the hosting provider is intended to manage the whole DNS zone. Individual records offer more control when you already use email, verification records, a CDN, or other services at the registrar or a separate DNS provider.

Before making changes, record the current DNS configuration. Pay particular attention to MX records for email, TXT records for domain verification and email authentication, and any records used by subdomains. A website migration can succeed while email fails if these records are overlooked.

Checklist by scenario

Scenario 1: Your cloud host provides nameservers

1. Log in to the hosting control panel and add the domain to the correct website, virtual host, or server configuration.
2. Copy the exact nameserver addresses supplied by the host. Do not replace them with an IP address; nameservers and server addresses serve different purposes.
3. At the domain registrar, open the nameserver or DNS delegation settings.
4. Replace the existing nameservers only after exporting or recording important DNS records.
5. Confirm the change and allow time for recursive DNS resolvers to refresh their cached information.
6. Check that the host’s DNS zone contains the expected A, AAAA, CNAME, MX, and TXT records.

This approach can be suitable for a new domain or a site whose DNS is not shared with other services. If the domain handles business email, review the mail records before switching nameservers.

Scenario 2: Your VPS has a fixed public IP address

1. Confirm the public IPv4 address assigned to the VPS. If you use IPv6, confirm the correct IPv6 address and whether the server is configured to accept traffic over it.
2. At the active DNS provider, create or update an A record for the root domain. Depending on the provider, the host or name field may be shown as @ or may be left blank.
3. Set the record value to the VPS public IPv4 address.
4. If IPv6 is configured correctly, add an AAAA record for the IPv6 address. Do not add one merely because IPv6 is available from the provider; the web server, firewall, and application must also support it.
5. Create a CNAME record for www that points to the root domain, such as example.com, or create a separate A record if your hosting design requires it.
6. Configure the web server to recognize both the root domain and www, then choose which version should redirect to the other.

An A record only directs traffic to the server. It does not install the website, configure the web server, open firewall ports, or activate HTTPS. Those steps must be completed on the VPS as well.

Scenario 3: Your platform provides a hostname

1. Add the custom domain inside the cloud hosting, managed WordPress, or deployment platform.
2. Copy the platform’s required target hostname. This is commonly used as the value of a CNAME record.
3. Create the requested record for www or another subdomain.
4. For the root domain, follow the platform’s documented method. Some platforms provide an A record, while others use an ALIAS, ANAME, or flattening feature.
5. Remove conflicting records for the same name if the platform specifically requires a single target.
6. Return to the platform and complete its domain verification step.

Do not substitute a CNAME for an A record at the root domain unless your DNS provider explicitly supports that behavior. DNS providers use different labels and capabilities, so follow the exact record type shown by the platform.

Quick troubleshooting decision tree

• The domain does not resolve anywhere: Check that the domain is active, the intended nameservers are applied, and the DNS zone contains the required records.
• The domain resolves to the old server: Check the active nameservers and the A, AAAA, or CNAME records. Cached results may also still be in circulation.
• The domain reaches the server but shows the wrong site: Check the web server’s virtual host or site configuration and confirm that both domain variants are included.
• The site works on one network but not another: Compare DNS results from different resolvers and check for stale caches, inconsistent nameservers, or an incorrect AAAA record.
• HTTP works but HTTPS fails: Confirm that the domain is included in the certificate request, the certificate is installed, and port 443 is allowed through the firewall.
• Email stopped after the change: Review MX and related TXT records, then verify which DNS provider is authoritative.

What to double-check

• Authoritative DNS: Make changes at the provider named by the domain’s current nameservers. Editing records at the registrar is ineffective if another DNS service is authoritative.
• Record conflicts: Check for duplicate A records, an old AAAA record, or a CNAME that points somewhere different from the intended host.
• Root and www behavior: Test both example.com and www.example.com. Decide whether one should redirect to the other and configure that behavior consistently.
• DNS TTL: A record’s time to live influences how long resolvers may retain an answer. Lowering TTL before a planned migration can make changes easier to roll back, but it does not force every resolver to update immediately.
• Server configuration: Confirm the application is deployed, the web server is listening on the expected ports, and the firewall allows HTTP and HTTPS traffic.
• SSL: Activate HTTPS only after DNS points to the correct environment or after the certificate system can validate domain control. Test the certificate on every hostname that users may visit.
• Application URLs: Content management systems may store the old domain in configuration or database values. Update those values carefully and test redirects, login pages, forms, images, and API callbacks.
• Monitoring and backups: Watch availability and server resources during the migration, and keep a restorable backup of the old site. The server monitoring checklist and website backup strategy guide provide useful preparation steps.

Common mistakes

Changing nameservers without copying email records is one of the most disruptive errors. A new DNS zone may contain website records but not the MX, SPF, DKIM, or verification records required by your mail provider.

Adding records at the wrong provider is also common. First identify the authoritative nameservers, then make the change there. A domain registrar and a hosting company may both display DNS controls, but only one zone is answering public queries.

Leaving an old AAAA record in place can cause inconsistent behavior. Some visitors may use IPv6 and reach an unconfigured server while IPv4 visitors reach the new host. Remove or correct the record unless IPv6 is ready.

Expecting DNS changes to fix server errors leads to wasted troubleshooting. If DNS resolves to the right IP but the browser shows a default page, timeout, or server error, inspect the web server, application, firewall, and hosting configuration.

Installing SSL too early or for only one hostname can leave users with certificate warnings. Include the required domain variants and test HTTPS after DNS and virtual host configuration are complete.

For larger moves, use a staging site and preserve the old environment until the new site has passed functional checks. The guide to using staging sites safely can help structure that process.

When to revisit

Use this checklist before every domain move, hosting migration, server replacement, or DNS provider change. Revisit it before seasonal traffic planning when you may move to more scalable cloud hosting, add a CDN, or change server locations. It is also worth reviewing after changes to email providers, deployment workflows, SSL automation, or IPv6 configuration.

When tools or control panels change, verify the labels used for root records, aliases, nameservers, and domain verification. Keep a simple record of the current DNS design: authoritative nameservers, website targets, mail records, subdomains, TTL choices, and rollback steps.

Before making the next change, complete this final action list:

1. Back up the website and export the current DNS zone.
2. Identify whether the change requires nameservers, A/AAAA records, or CNAME records.
3. Confirm the domain is added to the new hosting environment.
4. Check website, email, verification, and subdomain records.
5. Test DNS resolution, HTTP, HTTPS, redirects, and key application functions.
6. Monitor the old and new environments until traffic is consistently reaching the intended host.