How to Connect a Domain to Your Web App: DNS Records Explained Simply

Overview

If your goal is to connect a domain to a website or web app, DNS is the system that tells the internet where that app lives. In practice, you are usually doing one of a few things:

• Pointing the root domain, such as example.com, to a server or platform
• Pointing a subdomain, such as app.example.com or www.example.com, to another hostname
• Adding verification records for email, SSL, hosting, or third-party services
• Migrating traffic from one provider to another without breaking email or existing subdomains

The core record types are simpler than they look:

• A record: points a name to an IPv4 address
• AAAA record: points a name to an IPv6 address
• CNAME record: points one hostname to another hostname
• TXT record: stores text used for verification, email policies, or service configuration

For most developers, the most important distinction is A record vs CNAME. An A record points directly to an IP address. A CNAME points to another name, which then resolves to an IP behind the scenes. If your host gives you an IP address, you will likely use an A record. If your host gives you a target like project.hostingplatform.com, you will likely use a CNAME for a subdomain.

There are two practical constraints worth remembering:

1. The root domain, also called the apex or naked domain, often cannot use a standard CNAME at many DNS providers. Some providers offer ALIAS, ANAME, or CNAME flattening features to work around this.
2. DNS changes are not always visible immediately. Caching and time-to-live values mean a correct change may still take time to appear from every location.

Before you touch anything, collect four pieces of information from your hosting provider or deployment platform:

• The exact domain or subdomain you want to connect
• The required DNS record type
• The required target value, such as an IP address or canonical hostname
• Any verification steps, such as adding a TXT record before the platform will issue SSL or accept traffic

If you are deploying a static site, this DNS step usually comes right after the app is live on the platform. If you need a deployment walkthrough first, see How to Deploy a Static Website to Cloudflare Pages, Netlify, and Vercel.

Checklist by scenario

Use the scenario below that matches your setup. The goal is not to memorize every DNS rule, but to make sure you choose the correct record and avoid changing unrelated entries.

Scenario 1: Point a root domain to a single server

This is common when your app runs on a VPS, dedicated server, or load balancer with a stable public IP.

1. Find the IPv4 address of the server.
2. Create or update the A record for @ or the blank host, depending on your DNS provider UI.
3. If your host supports IPv6 and you want it enabled, also create the matching AAAA record.
4. Check whether an old A or AAAA record still points to a previous server. Remove stale duplicates if they are not part of an intentional multi-IP setup.
5. Make sure your web server is configured to respond for the new domain, not just the default host.
6. Confirm SSL is set up after DNS begins resolving correctly.

Best fit: custom infrastructure, reverse proxies, traditional web hosting, or cloud VMs.

Scenario 2: Point www to a hosting platform

This is one of the most common patterns for modern platforms. The provider gives you a hostname rather than an IP.

1. Create a CNAME record for www.
2. Set the target to the hostname provided by the platform, such as yourapp.host.example.
3. Do not also create an A record for www unless the provider specifically asks for it.
4. Add the domain inside the hosting platform dashboard so it knows to accept requests for that hostname.
5. Set your preferred redirect behavior: either example.com redirects to www.example.com, or the reverse.

Best fit: static site hosts, app hosting platforms, managed frontends, and CDN-backed deployments.

Scenario 3: Connect the apex domain and www

Many teams want both example.com and www.example.com to work, with one redirecting to the preferred version.

1. Choose the canonical domain first. This avoids split traffic and inconsistent URLs.
2. For www, use a CNAME if the platform provides a hostname target.
3. For the apex domain, use the record type your DNS provider and host support. This may be an A record, AAAA record, or a provider-specific flattening feature.
4. Set a redirect so only one version is canonical.
5. Verify SSL covers both names.

This is the setup where many people get stuck. The platform may support subdomains with a CNAME but require different handling for the apex domain. Read the provider instructions carefully rather than forcing the same record type everywhere.

Scenario 4: Add domain verification with TXT records

TXT records do not route traffic. They are typically used to prove domain ownership or support email-related policies.

1. Copy the TXT value exactly as provided.
2. Add it under the correct host name. Some providers use @, some use a specific label, and some expect a subdomain-like host.
3. Keep quotation marks only if your DNS provider requires or preserves them safely.
4. Wait for propagation and run verification again from the service dashboard.
5. Do not delete existing unrelated TXT records unless you are certain they are obsolete.

TXT records are often used for domain verification before a platform will activate custom domains or certificates. They are also common for SPF, DKIM, and DMARC in email setups, which means accidental edits can break mail delivery even if your website still works.

Scenario 5: Move a domain from one provider to another

Migrations are where DNS work becomes operational work. The safest path is usually to reduce surprises rather than rush the cutover.

1. Inventory all existing records before making changes: A, AAAA, CNAME, MX, TXT, redirects, and any special records.
2. Lower TTL values in advance if your provider allows it and if you have enough lead time.
3. Set up the new host fully before changing DNS.
4. Replicate all non-website records you still need, especially email-related ones.
5. Change only the records required for the site first.
6. Test from multiple networks and devices after the cutover.
7. Keep the old infrastructure available during the transition window if possible.

For app launches, migrations, and environment handoffs, a simple record inventory stored in version control can be surprisingly helpful. If your project already manages structured configuration, the comparison mindset from JSON vs YAML vs TOML: Which Config Format to Use in Modern Projects applies here too: clarity beats cleverness.

Scenario 6: Connect API or service subdomains

Not every DNS change is for the main site. Teams often need subdomains like api.example.com, cdn.example.com, or status.example.com.

1. Confirm whether the target should be a direct IP or another hostname.
2. Use an A/AAAA record for direct IP targets and a CNAME for hostname targets.
3. Check CORS, SSL, and application-level host settings after DNS resolves.
4. Make sure environment variables, callbacks, and API documentation use the final hostname.

This scenario often fails not because DNS is wrong, but because the application still expects the old host. DNS is only one layer of the change.

What to double-check

Once you have added or updated records, use this section as your pre-launch review. These checks catch many of the issues that look like “DNS problems” but are actually configuration mismatches.

1. Are you editing the authoritative DNS zone?

If your domain registrar and DNS provider are different, make sure you are changing records in the service actually named in the domain's nameserver settings. Updating the wrong dashboard is a classic time sink.

2. Did you use the correct host name format?

DNS provider interfaces vary. Some expect:

• @ for the root domain
• www for the www subdomain
• Only the relative label, not the full domain name

Others let you enter the full hostname. Mixing these patterns can create malformed records or duplicate names.

3. Are old records conflicting with the new ones?

It is easy to leave behind an old A record for www while adding a new CNAME, or to keep multiple IPs that were once valid but no longer should receive traffic. Review all records for the exact host you are changing.

4. Did you add the domain inside the hosting platform?

Many platforms require two steps:

1. Add the DNS record at your DNS provider
2. Add and verify the custom domain in the hosting dashboard

Skipping the second step often results in DNS resolving correctly while the platform still returns a default page, certificate warning, or not found response.

5. Is SSL configured for the final hostname?

A working DNS record does not guarantee a valid certificate. Check both the root domain and any subdomains you expect to serve over HTTPS. If the platform issues certificates automatically, it may still need time and successful domain verification.

6. Are redirects intentional?

Confirm that:

• http redirects to https
• Non-canonical hosts redirect to the canonical host
• Old paths still resolve if the migration needs backward compatibility

A DNS change can expose old redirect rules that were harmless before but now create loops or send traffic to the wrong environment.

7. Are email records untouched unless you meant to change them?

MX and TXT records for email are easy to overwrite during a rushed migration. If your task is only to point a domain to a website, treat mail settings as a separate review item.

8. Did you allow enough time for propagation and cache expiry?

DNS propagation is rarely all-or-nothing. Some users may reach the new destination while others still see the old one for a period of time. Plan launches with that overlap in mind.

Common mistakes

This section is the short list of issues worth checking first when a domain setup does not behave as expected.

Using a CNAME at the apex when your setup does not support it

This is one of the most common reasons root domains fail while subdomains work. If the provider instructions mention ALIAS, ANAME, or flattening, follow that path rather than forcing a standard CNAME.

Changing nameservers by accident

Pointing a domain to a website usually means editing DNS records, not changing the domain's nameservers. Switching nameservers without recreating the full zone can take the whole domain offline, including email.

Adding multiple records that fight each other

If www has both a CNAME and an A record, or if old and new IPs remain mixed unintentionally, traffic may behave inconsistently. Keep each hostname clean and purposeful.

Forgetting the application layer

Even with correct DNS, the app may reject requests if:

• Allowed hosts are not updated
• Reverse proxy rules still expect the old domain
• Environment variables contain outdated callback URLs
• OAuth or webhook settings still use a previous hostname

This is common for APIs and auth flows. If you are debugging callback URLs or query parameters during testing, tools such as a URL encoder and decoder can help verify values before you blame DNS.

Deleting TXT records too aggressively

Not every TXT record is disposable. Some support domain ownership verification, while others support email authentication. Remove them only if you know what system depends on them.

Testing from one place only

Your laptop, office network, VPN, and mobile connection may not all resolve the domain the same way at the same time. Check from more than one path before concluding the change failed.

Skipping a rollback plan

For production cutovers, know what you will do if the new target fails. That may mean preserving old records, documenting previous values, and keeping the old environment available long enough to reverse course.

When to revisit

DNS is not something you configure once and forget forever. It is worth revisiting whenever the underlying infrastructure, traffic patterns, or ownership model changes. Use the list below as an operational reminder.

Revisit DNS before these events

• A major launch, redesign, or platform migration
• Moving from a single server to a managed hosting platform
• Adding a CDN, proxy, or edge platform
• Introducing new subdomains for APIs, assets, docs, or status pages
• Changing registrars, DNS providers, or nameservers
• Renewing SSL strategy or revising redirect rules
• Auditing email deliverability and domain verification records

A simple recurring review checklist

1. Export or document the current DNS zone.
2. Mark which records support the website, which support email, and which support third-party services.
3. Confirm the canonical domain and redirect behavior are still intentional.
4. Check for stale A, AAAA, CNAME, and TXT records left by old platforms.
5. Verify that important subdomains still point where you expect.
6. Retest SSL coverage and application host configuration.
7. Store the final approved record set somewhere your team can find quickly.

If your team uses a launch checklist, add DNS as a dedicated section rather than a single line item. It deserves a small preflight of its own. The time cost is low, and the failure cost is usually high.

As a final rule of thumb: when you need to point a domain, make the smallest change that accomplishes the goal. Do not redesign the whole DNS zone during a routine deployment. Record the before state, update only the required hostnames, validate the result, and then return later for cleanup once traffic is stable.

That approach is what makes a domain setup guide reusable. Whether you are connecting a root domain to a cloud VM, mapping www to a hosted frontend, or verifying a service with TXT records, the same sequence applies: identify the hostname, choose the right record type, avoid touching unrelated entries, and validate both DNS and app-level behavior after the change.