How to Connect a Domain to Cloud Hosting: DNS Records, Nameservers, and SSL Setup

Overview

A domain name and a cloud server are separate services. The domain is registered through a registrar, while the website runs on a hosting platform, virtual private server, or other cloud infrastructure. DNS management provides the instructions that connect the two.

There are two common ways to make that connection:

• Change nameservers: Delegate DNS management to the hosting provider or a managed DNS service. The provider then becomes responsible for the domain’s DNS zone.
• Keep the current nameservers: Leave DNS at the registrar or existing DNS provider and add or edit only the records required for the cloud server.

Neither approach is universally better. Changing nameservers can simplify a new deployment when the hosting provider supplies useful DNS automation. Keeping existing nameservers is usually less disruptive when the domain already supports email, verification records, subdomains, or other services that must remain intact.

Before making changes, record the current DNS configuration. Save the nameservers and every existing record, including MX, TXT, CNAME, and verification entries. This small preparation step makes it easier to restore a setting or compare the old and new configuration during a migration.

If the application itself still needs to be deployed, complete that work before switching live traffic. For example, you can review how to deploy a static site with a custom domain, how to deploy a Node.js app on a VPS, or deploy Docker on a VPS.

Checklist by scenario

Scenario 1: A new domain and a new cloud server

1. Confirm the domain is registered and not locked against changes that would prevent management.
2. Find the public IPv4 address of the cloud server. If the provider supplies IPv6, decide whether you will publish an AAAA record as well.
3. Choose whether DNS will be managed by the cloud host, the registrar, or a separate managed DNS provider.
4. Point the root domain, commonly written as @, to the server with an A record. Add an AAAA record only when the server is configured to accept IPv6 traffic.
5. Point www to the root domain with a CNAME, or use an A record if your provider requires it.
6. Configure the web server or application to recognize both the root domain and the www hostname.
7. Open the required web ports in the server firewall and cloud security rules, then test the site over HTTP before requesting a certificate if your deployment process requires that sequence.
8. Enable HTTPS and redirect HTTP to HTTPS after the certificate is issued and tested.

Scenario 2: A domain with existing email

Do not replace the entire DNS zone merely to point the website at a new server unless you have copied all required records. Keep the existing MX records unless the email provider is also changing. Preserve TXT records used for SPF, DKIM, DMARC, domain verification, or third-party services. A web migration can succeed while email silently fails if these records are omitted.

For a detailed email-focused workflow, see how to launch a website on a new domain without breaking email.

Scenario 3: A staging or subdomain deployment

For a staging application, create a separate hostname such as staging.example.com and point it to the staging server with an A or CNAME record. Keep production records unchanged. Make sure the staging environment is protected with authentication or network controls if it contains unfinished work, test data, or administrative tools. The guide to staging and production domains provides a useful planning model.

Scenario 4: A hosting migration

Lowering the DNS TTL before a planned migration may help resolvers refresh records sooner, but it does not guarantee immediate worldwide convergence. Build and test the replacement server first, copy the current DNS records, change only the necessary web records, and monitor both the old and new environments during the transition. Use the website migration checklist when the change involves more than a simple DNS update.

What to double-check

DNS records

An A record maps a hostname to an IPv4 address. An AAAA record maps it to an IPv6 address. A CNAME points one hostname to another hostname and is commonly used for www or provider-managed services. MX records direct email to mail servers. TXT records store text-based configuration, including ownership verification and email authentication. A domain may have multiple records of some types, so do not delete existing entries without confirming their purpose.

Nameservers and delegation

Nameserver changes happen at the registrar, while individual record edits happen at the active DNS provider. Editing records in the wrong dashboard has no effect. Confirm the authoritative nameservers before troubleshooting an apparently ignored change. If you recently changed nameservers, allow time for different resolvers to observe the new delegation.

Server configuration

DNS only directs traffic; it does not configure the application. The cloud server must have the correct virtual host, reverse proxy, container routing, or application configuration. Confirm that the service listens on the expected interface and that firewall rules permit web traffic. If you are sizing a new server, review the guide to cloud hosting resources.

SSL and canonical access

Request a certificate for every hostname visitors will use, such as the root domain and www. Certificate validation can fail when DNS points to the wrong server, a required validation record is missing, or the web server is not reachable. After installation, test HTTPS directly and choose one canonical hostname. Redirect the alternate hostname consistently rather than allowing several versions to behave differently. See the SSL certificate setup guide for a separate certificate checklist.

Common mistakes

• Changing nameservers without copying records: This can remove email routing, verification records, and subdomains from the active zone.
• Using the wrong record type: A CNAME cannot generally be placed at the root of a zone, and an A record cannot contain a hostname instead of an IP address.
• Adding a duplicate or conflicting record: Multiple A records may distribute traffic, while conflicting CNAME or MX entries can produce unexpected results. Follow the hosting provider’s exact instructions.
• Forgetting the application hostname: A server can be reachable by IP while the application rejects the domain because its virtual host, framework configuration, or allowed-host list is incomplete.
• Treating propagation as a single event: DNS caches refresh at different times. Check from more than one network and use DNS lookup tools to compare authoritative answers with recursive resolver results.
• Issuing SSL too early: A certificate request will be easier after DNS, firewall rules, and hostname configuration are working.
• Testing only one URL: Check the root domain, www, HTTP, HTTPS, important subdomains, and any mail-related records that were supposed to remain unchanged.

When to revisit

Use this checklist before each domain launch, hosting migration, seasonal infrastructure review, or major deployment workflow change. Revisit it when you move DNS providers, add IPv6, introduce a CDN or reverse proxy, change email platforms, split staging from production, or replace a single server with multiple application nodes.

For a practical final pass, confirm the following:

1. The authoritative nameservers are the ones you intended to use.
2. The root domain and required subdomains resolve to the correct destination.
3. Existing MX, SPF, DKIM, DMARC, and verification records are present and valid.
4. The cloud server accepts traffic for the domain and the application serves the correct content.
5. HTTPS works for every public hostname, with a consistent redirect to the preferred URL.
6. Monitoring, backups, renewal notifications, and access documentation are in place.

Record the final DNS zone, server address, certificate method, and responsible account in your operations notes. That documentation turns the next domain connection or deployment into a controlled repeatable task rather than a search for forgotten settings.