How to Point a Domain to a Server: A Record, CNAME, Nameservers, and TTL Explained

Overview

If your goal is to point domain to server infrastructure, you are usually making one of four changes:

• Add or update an A record to send a hostname to an IPv4 address.
• Add or update a CNAME to alias one hostname to another hostname.
• Change nameservers to move DNS hosting from one provider to another.
• Adjust TTL to influence how long resolvers may cache the answer.

The confusing part is that these actions solve different problems. Many DNS issues happen because the wrong action was used for the job.

Use this quick model:

• Use an A record when you have a server IP and want a hostname such as example.com or app.example.com to resolve directly to that IP.
• Use a CNAME when a provider gives you a target hostname such as project.hosting-platform.example and instructs you to point a subdomain to it.
• Change nameservers when you want another DNS provider to become the source of truth for the whole zone.
• Think about TTL before changes, migrations, and launches. TTL explained in DNS terms is simple: it is the cache lifetime of the answer, not a guarantee of exact timing.

This article focuses on operational clarity rather than provider-specific clicks. Registrar and hosting interfaces change often, but the underlying checklist remains useful.

One more rule matters: your registrar, your DNS host, and your web host may be three different systems. Buying a domain from one company does not mean that company is handling DNS or serving your site. Before you touch anything, identify all three.

If you are using Cloudflare as your DNS layer, see our Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types. If you are troubleshooting delays after a change, our DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays goes deeper on dns propagation check workflows.

Checklist by scenario

This section gives you scenario-based steps you can return to before making a live DNS change.

Scenario 1: Point the root domain to a single server IP

Typical use case: you have a VPS, cloud instance, or load balancer with a stable public IP and want example.com to open your site.

1. Confirm where authoritative DNS is hosted. Do not edit records at the registrar if another DNS provider is authoritative.
2. Collect the target IPv4 address from your hosting or infrastructure dashboard.
3. Create or update an A record for the root host, often shown as @.
4. Set a reasonable TTL. For planned changes, many teams temporarily lower TTL ahead of time, then raise it again later.
5. Save the record and test with dig, nslookup, or a propagation checker.
6. Make sure your server is configured to answer for that hostname. DNS alone does not make the site work.

If your app is behind Nginx, pair the DNS change with web server configuration. Our Nginx Reverse Proxy Setup Guide for Node.js, Docker, and SSL is a useful companion when the domain resolves correctly but the app still does not serve traffic.

Scenario 2: Point a subdomain to a provider hostname

Typical use case: a platform asks you to set www, app, or docs to a target hostname.

1. Confirm the exact hostname the provider gave you.
2. Create a CNAME record for the subdomain, such as www or app.
3. Point it to the provider target hostname exactly as instructed.
4. Check whether the provider requires domain verification with a TXT record before the CNAME becomes active.
5. Wait for DNS caches to update, then verify both the DNS answer and the application-level status in the provider dashboard.

This is the most common a record vs cname decision. If the target is a hostname, use CNAME unless the provider explicitly says otherwise. If the target is an IP address, use A or AAAA as appropriate.

For hosted frontend platforms, these two guides cover common workflows and edge cases: How to Connect a Domain to Netlify: DNS Records, SSL, and Common Fixes and How to Connect a Domain to Vercel Without DNS Errors.

Scenario 3: Move DNS to another provider by changing nameservers

Typical use case: you want centralized management, better automation, or advanced features at a different DNS provider.

1. Export or document the current DNS zone before making any change.
2. Recreate all required records at the new DNS provider first. That includes web, mail, verification, and service records.
3. Verify records carefully: A, AAAA, CNAME, MX, TXT, SRV, and any provider-specific records.
4. Only after the new zone is complete, change nameservers at the registrar to the new provider values.
5. Monitor resolution from multiple networks until the new nameservers are consistently authoritative.

Nameserver changes are all-or-nothing for the zone. This is where teams often break email, staging apps, or forgotten subdomains. If your domain handles business email, review all authentication and routing records before you switch. Our SPF, DKIM, and DMARC Setup Guide for Google Workspace, Microsoft 365, and Custom Domains is essential if mail flows through the same domain.

Scenario 4: Prepare for a migration or cutover

Typical use case: moving a site between servers, clouds, or platforms with minimal delay.

1. Lower TTL well before the planned change if the current provider allows it and the record is not already widely cached.
2. Confirm the new destination is fully ready before changing DNS.
3. Keep old infrastructure available during the transition window when possible.
4. Change the necessary A, AAAA, or CNAME records.
5. Validate DNS answers, TLS, redirects, and app health checks.
6. After stability is confirmed, raise TTL back to a more normal value to reduce query churn.

TTL is useful for planned cutovers, but lowering it at the last minute does not retroactively shorten caches that already stored the old answer. That is one reason teams sometimes think DNS is "ignoring" a new TTL.

Scenario 5: Point a domain to a Dockerized app on your own server

Typical use case: a small production app runs in containers on a Linux host.

1. Point the domain or subdomain to the server IP using an A record.
2. Make sure the firewall and security group allow inbound traffic on the needed ports.
3. Terminate TLS and route traffic with Nginx, Caddy, Traefik, or a managed load balancer.
4. Verify the container listens on the expected internal port and the reverse proxy points to the right upstream.
5. Test from outside the host, not just locally.

If you are building this setup from scratch, combine this article with our Docker Deployment Tutorial for Small Production Apps and GitHub Actions Deployment Guide: Build, Test, and Deploy Web Apps Reliably.

Scenario 6: Automate repeated DNS changes

Typical use case: you manage many domains, create preview environments, or want DNS changes reviewed in version control.

This is where dns automation becomes valuable. A manual dashboard change may be fine once, but repeated edits benefit from scripts, APIs, or infrastructure as code.

• Use provider APIs for repeatable record creation and updates.
• Store desired records in code where practical.
• Use clear naming conventions for environments and subdomains.
• Build a rollback plan for destructive changes such as nameserver migrations.
• Record ownership: who can approve DNS changes and who receives alerts.

If you are exploring how to automate dns records, look for providers with solid API support and clean zone export options. Many teams start with dashboard edits, then move to scripts or Terraform as the number of records and environments grows.

What to double-check

Most DNS issues are not caused by DNS itself. They come from incomplete context. Before and after every change, verify these items.

1. Are you editing the authoritative DNS zone?

If nameservers point to Provider B, changing records at Provider A does nothing. Always confirm the active authoritative nameservers first.

2. Did you choose the correct hostname?

@, blank host, and the full root domain may be displayed differently depending on the interface. Likewise, www and app are not interchangeable.

3. Are there conflicting records?

A hostname generally should not have a CNAME alongside other record types at that same name. Duplicate A records may be intentional, but duplicate or stale records often cause confusing results.

4. Did you account for IPv6?

If you publish an AAAA record, clients may use it. If your server is not correctly configured for IPv6, remove the AAAA record or finish the IPv6 setup.

5. Is the web server ready for the domain?

DNS can resolve perfectly while the app still fails because the server block, virtual host, or TLS configuration does not match the hostname.

6. Did you preserve email records?

When changing nameservers, teams often remember the website and forget MX, SPF, DKIM, DMARC, or provider verification TXT records. The result is silent mail trouble that shows up later.

7. Is proxying involved?

Some DNS providers can proxy HTTP traffic. That changes how requests reach your origin and can affect TLS, real client IP handling, and troubleshooting steps. Know whether a record is DNS-only or proxied.

8. Did you verify from more than one vantage point?

Your laptop cache, browser cache, corporate resolver, and public DNS resolvers may disagree temporarily. Test with a command-line query and at least one external checker.

9. Did you wait long enough for caches to expire?

TTL explained dns in one sentence: resolvers may keep old answers until their cache expires, so seeing mixed results for a while is normal.

10. Do you have a rollback note?

For important production changes, write down the exact previous values before editing. A rollback should not depend on memory.

Common mistakes

These are the mistakes that repeatedly slow down launches and troubleshooting.

• Using a CNAME at the wrong place. Many providers expect a CNAME on a subdomain like www, not on the apex root. Interfaces and DNS provider features vary, so follow the host-specific rule for your setup.
• Changing nameservers when only one record needed updating. A full nameserver move is much riskier than editing a single A or CNAME record.
• Assuming propagation is instant. Some changes appear quickly from one network and slowly from another.
• Lowering TTL too late. TTL changes help most when done before the migration window.
• Forgetting non-web records. Mail, verification, SIP, calendar, and other services can depend on DNS records that are easy to overlook.
• Ignoring trailing dots, host formatting, or provider UI quirks. DNS interfaces differ. Some expect relative names, some display fully qualified names, and some normalize values automatically.
• Skipping application validation. A correct DNS answer does not guarantee the app, certificate, or redirect rules are correct.
• Not documenting ownership. In shared teams, people may not know who controls the registrar, DNS host, or cloud account.

A useful habit is to separate DNS troubleshooting into layers:

1. Authority: which nameservers are authoritative?
2. Record data: what do A, AAAA, CNAME, MX, and TXT records actually say?
3. Propagation: what do different resolvers currently return?
4. Transport: does the server accept the request on the right ports?
5. Application: does the host header, TLS, and app routing match the domain?

Working through those layers in order is usually faster than guessing.

When to revisit

This topic is worth revisiting any time the surrounding systems change, not just when a website is down. Use the checklist below as an operational reminder.

• Before a platform migration. Moving from one host, cloud, or frontend platform to another often changes whether you need an A record, CNAME, or nameserver move.
• Before seasonal traffic or launch windows. If a domain change could affect a launch, reduce risk by reviewing TTLs, rollback steps, and monitoring ahead of time.
• When consolidating tools. If you are evaluating the best dns provider for developers or reducing vendor sprawl, revisit nameserver strategy and automation options.
• When introducing CI/CD or infrastructure as code. DNS changes can become part of a deployment workflow, but only after your team has a clear ownership and review process.
• When email or verification requirements change. New providers may require TXT records, MX changes, or updated authentication records.
• When adding subdomains for environments. Staging, preview, customer-specific, and regional subdomains increase the value of consistent naming and automation.
• When troubleshooting recurring incidents. Repeated DNS issues usually point to documentation gaps, unclear ownership, or inconsistent provider usage.

For a practical action plan, save this pre-change checklist:

1. Identify the registrar, authoritative DNS provider, and hosting platform.
2. Write down the exact current records and nameservers.
3. Choose the smallest effective change: A record, CNAME, or full nameserver migration.
4. Lower TTL in advance if a planned cutover needs faster turnover.
5. Validate web, email, and verification records together.
6. Run a dns propagation check after the change.
7. Test the application, redirects, TLS, and server configuration.
8. Raise TTL again after the system is stable.
9. Document the final state for the next person, including why the record exists.

That final step is easy to skip, but it is often what turns one-off fixes into reliable DNS operations. The interfaces will change over time, and providers will rename features, but the core practice remains the same: know who is authoritative, use the correct record type for the target, plan TTLs before the change, and verify the full path from resolver to application.