Common DNS Records for Static Sites: A, CNAME, TXT, and WWW Setup Explained

Overview

For a static site, DNS does one job: it tells browsers where your domain should point. The challenge is that “where” can mean different things depending on your hosting platform. Some providers ask you to point the apex domain with A records. Others prefer an ALIAS- or ANAME-style setup at the root if your DNS provider supports it. Many ask you to use a CNAME for www. Nearly all platforms also use TXT records at some point for domain verification, email safety, or ownership checks.

If you only remember one rule, make it this: decide which hostname is canonical first, then configure DNS around that decision. In practice, that means choosing whether users should land on example.com or www.example.com, then making the other version redirect to it at the hosting or platform level. DNS points traffic; redirects consolidate it.

Here is the short reference:

• A record: Points a hostname to an IPv4 address.
• AAAA record: Points a hostname to an IPv6 address.
• CNAME record: Points one hostname to another hostname.
• TXT record: Stores text-based verification or policy data.

For most static site setups, the common pattern looks like this:

• The apex domain, often written as @, uses A records or a root-compatible aliasing method if the provider requires it.
• www uses a CNAME to the host your platform gives you, or sometimes to the apex domain if your provider allows that pattern and your platform supports it.
• TXT records are added for ownership verification or related services.
• Your hosting provider handles SSL and redirects after the DNS records resolve correctly.

This matters not just for availability, but also for maintainability. If you are hosting quick demos, standalone HTML pages, or simple documentation sites, DNS is often the last step before sharing a stable public URL. A clean setup reduces confusion for stakeholders and makes future platform changes easier.

Checklist by scenario

Use the scenario closest to your setup. The goal is not to memorize every rule, but to apply the right pattern with confidence.

Scenario 1: You want both example.com and www.example.com to work

This is the most common static hosting setup and usually the safest default.

1. Choose the canonical hostname. Decide whether the final public URL should be example.com or www.example.com.
2. Check your host’s domain instructions. Some hosts want the apex on A records and www on a CNAME. Others want both added inside the platform first, then verified with DNS.
3. Set the apex record. Add the required A records, or use your DNS provider’s root aliasing option if supported and recommended by the host.
4. Set the www record. Add a CNAME for www pointing to the hostname your host provides.
5. Add required TXT verification. If the host asks for a TXT record, enter it exactly as shown.
6. Configure redirects in hosting. DNS alone does not decide which hostname users should stay on. Set a redirect so the non-canonical version forwards to the canonical version.
7. Wait for propagation, then test both versions. Check that both hostnames resolve and that one cleanly redirects to the other.

This setup gives you flexibility. It also helps when users type a domain with or without www, and it avoids splitting traffic across two accessible versions of the same site.

Scenario 2: Your host tells you to use A records for the root domain

This is common because the apex domain cannot always use a standard CNAME under traditional DNS rules.

1. Find the exact IP addresses your host provides. Do not substitute old values from another project.
2. Create A records for @. Add each address exactly once unless your DNS provider requires a different interface.
3. Remove conflicting root records. If an old A record, old forwarding rule, or incompatible synthetic record exists, clean it up first.
4. Add a www CNAME if instructed. Many platforms still want www to point to a hostname, not an IP.
5. Verify SSL and redirect behavior after resolution. A correct DNS setup is only half the job.

When comparing a record vs cname static site setups, the practical distinction is simple: A records point directly to IP addresses, while CNAME records point to another hostname that may change underneath. Static hosts often prefer CNAMEs for subdomains because they can manage the final destination more flexibly.

Scenario 3: You want to use only www

Some teams prefer www as the canonical hostname because it keeps the root domain free for other DNS functions and often maps neatly to common host instructions.

1. Add a CNAME for www. Point it to the hostname supplied by your static hosting provider.
2. Decide what happens at the apex. Your root domain should usually redirect to www, either via your registrar’s forwarding feature or your hosting platform if supported.
3. Confirm SSL coverage for both names. Even if www is canonical, users may still try the apex.
4. Test redirect chains. Avoid multiple hops such as apex to old domain to www.

A good www cname setup is often the least fragile option when a platform strongly prefers CNAME-based mapping.

Scenario 4: Your platform requires TXT verification before the domain goes live

TXT records are often temporary in purpose but important in practice.

1. Copy the host and value exactly. TXT records fail most often because of small formatting mistakes.
2. Check whether the record goes on the root or a subdomain. A TXT on @ is different from a TXT on _verify or another labeled host.
3. Keep existing unrelated TXT records intact. Multiple TXT records can coexist. Do not delete SPF, DMARC, or other email-related entries unless you know they are obsolete.
4. Wait, then re-run verification inside the host’s dashboard. Verification usually depends on propagation and caching.

TXT records do not route web traffic, but they are often the missing step when trying to connect custom domain html hosting correctly.

Scenario 5: You are moving a static site from one host to another

Migrations create the highest risk of downtime because old and new records can overlap.

1. Export or document the current DNS state. Capture screenshots or a zone file if available.
2. Lower TTL in advance if practical. This can help speed up visible cutover, though resolvers may still cache older values for a while.
3. Add the domain in the new host first. Complete any verification requirements before changing the public records.
4. Update DNS only after the new host is ready. Avoid pointing traffic to an unprovisioned site.
5. Confirm redirects, SSL, and any CDN behavior. The move is not done when the record resolves; it is done when the site behaves normally.

If you are running a lightweight project, such as a single landing page or a demo built from a standalone HTML file, this is also a good time to review asset structure and page readiness. Related checks can help: Single-File HTML Apps: When to Keep Everything in One File and When to Split Assets, HTML Validator Tools Compared: Catch Broken Markup Before You Publish, and Responsive HTML Page Checklist: What to Test Before You Share a Live Link.

What to double-check

Before you save changes, run through this short validation list. It catches most preventable DNS issues for static hosting.

• Are you editing the authoritative DNS zone? If your nameservers point to a DNS provider other than your registrar, changes must be made where the zone is actually hosted.
• Did you use the correct host label? @, blank root, and explicit domain labels are handled differently across DNS interfaces.
• Do you have duplicate or conflicting records? For example, a CNAME generally should not coexist with other record types on the same hostname in standard DNS usage.
• Did you copy trailing dots or hostnames correctly? Some interfaces append the domain automatically; others expect a fully qualified value.
• Are old forwarding rules still active? Registrar forwarding can conflict with host-managed redirects.
• Did you allow time for propagation? A successful save does not mean every resolver sees the change immediately.
• Is the site added and verified inside the hosting platform? Some hosts will not serve traffic until the domain is recognized in their dashboard.
• Are SSL certificates provisioned for every hostname you expose? A domain may resolve but still show certificate errors if provisioning has not completed.

After DNS looks correct, test the site from a user perspective, not just from a DNS lookup perspective. Visit both the apex and www versions. Confirm the preferred one loads over HTTPS. Check that pages, images, CSS, and scripts all work on the live domain. For broader page-level validation, these references are useful: How to Test a Static HTML Page Across Browsers Without a Full QA Stack and Static Site Performance Checklist: Core Web Vitals Fixes for Simple HTML Projects.

Common mistakes

Most DNS trouble for static sites comes from a small set of repeat problems. These are worth checking before assuming the host is at fault.

Using a CNAME at the root when the provider does not support it

The apex domain is the source of many configuration errors. If your DNS provider does not support root aliasing and your host requires root connectivity, you may need A records instead. Read the host instructions literally for the apex.

Forgetting that DNS and redirects are different layers

Pointing both example.com and www.example.com to the same site does not automatically create a redirect. Without explicit canonical handling, both may stay accessible, which is untidy for users and search engines.

Deleting TXT records that seem unrelated

Many teams clean DNS while troubleshooting and accidentally remove email or verification records. TXT entries often look opaque, but they may support systems outside your website. Remove only what you can identify safely.

Changing nameservers by mistake

Some registrars place nameserver controls close to DNS record controls. Replacing nameservers is a much bigger change than editing a single record and can disconnect existing services.

Assuming propagation is instant everywhere

Even when the authoritative zone is correct, local caches, ISP resolvers, and browser caching can delay what you see. Test methodically before making another round of changes that may compound the problem.

Leaving stale records during a host migration

Old A records, legacy CNAMEs, unused verification TXT records, and forwarding rules can create ambiguous behavior. Clean migrations usually work better than partial ones, but cleanup should be deliberate rather than impulsive.

Not checking the live site after DNS resolves

A record may point correctly while the site still has broken paths, mixed content, or missing assets. Once the domain is live, review cache behavior and asset delivery too. If your HTML updates are not appearing as expected, Cache-Control for Static HTML Sites: Best Practices for Fast Updates Without Stale Pages is a useful follow-up. If you are still optimizing final delivery, see HTML, CSS, and JavaScript Minification Guide for Faster Static Pages.

When to revisit

DNS is not a one-time setup. It is stable when correct, but it should be revisited whenever the surrounding workflow changes. The best time to review your static hosting DNS is before a launch, before a seasonal traffic push, or when moving between hosting tools, registrars, or CI/CD workflows.

Revisit this setup if any of the following is true:

• You are changing static hosting providers.
• You are switching registrars or DNS providers.
• You want to add or remove www.
• You are consolidating multiple microsites or landing pages.
• You are adding CDN, SSL, or redirect rules in a new platform.
• You are troubleshooting intermittent reachability or certificate issues.
• You are preparing a public demo link for clients, stakeholders, or campaigns.

A practical maintenance routine looks like this:

1. Keep a plain-text record of your intended DNS state. Note the apex record type, the www target, and any TXT verification entries you expect to keep.
2. Define one canonical hostname per project. Decide this early and make redirects explicit.
3. Review DNS before major launches. Confirm nothing old is still attached to the zone.
4. Test from the browser after every DNS change. Do not stop at a lookup tool.
5. Review adjacent site-health checks. After domain setup, validate markup, responsiveness, and performance so the live link is ready to share.

If you need supporting workflow references after DNS is done, these are sensible next reads: Best Online HTML Editors and Live Preview Tools for Quick Prototypes and Embed Fonts, Images, and CSS in One HTML File: Pros, Cons, and Size Limits.

The practical takeaway is simple: for a reliable static hosting dns guide, decide your canonical domain, map the apex and www intentionally, preserve necessary TXT records, and verify the live behavior after propagation. That checklist stays useful even as registrars, dashboards, and hosting instructions evolve.