How to Set Up the Right DNS Records for Your Website

The right DNS setup starts by identifying the authoritative DNS provider, then copying the exact A, AAAA or CNAME targets supplied by your web host. Point the root domain and www deliberately, keep mail records separate, and verify both names after caches have had time to refresh.

Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.

What DNS does for a website

Domain Name System (DNS) turns names such as example.com into destinations that browsers can contact. A browser first asks a recursive resolver for the records published by your domain’s authoritative nameservers. The resolver returns an IPv4 address, IPv6 address or hostname, and the browser then connects to the web server or delivery network at that destination.

#	Preview	Product	Price
1		DNS and BIND (5th Edition)	$38.88	Buy on Amazon
2		DNS & BIND Cookbook	$17.30	Buy on Amazon
3		DNS and BIND	$17.96	Buy on Amazon
4		DNS and BIND on IPv6: DNS for the Next-Generation Internet	$25.79	Buy on Amazon
5		DNS and BIND, Fourth Edition	$37.46	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Registration and DNS hosting are separate jobs. Your registrar keeps the domain registration and publishes the delegation (NS) records. The authoritative DNS host stores the zone and answers queries for the records inside it. Editing a zone at a dashboard that is not named by the domain’s NS delegation changes nothing for visitors.

Before you add a record

Find the authoritative DNS host

Check the domain’s current NS records with a registrar lookup, a DNS inspection service or a command such as dig NS example.com. The returned nameservers identify the service whose zone you must edit. If you are moving to a different DNS service, replace the registrar’s nameservers with the exact pair (or set) supplied for your zone, wait for that delegation to take effect, and only then manage records in the new service.

#1 Best Overall

Sale

DNS and BIND (5th Edition)

$38.88

Buy on Amazon

A Cloudflare zone is a common example of this model: Cloudflare gives you nameservers for the zone, but you must set those nameservers at the registrar before Cloudflare’s record editor is authoritative. Do not delete the old zone until you have copied required web, mail, verification and security records.

Collect the host’s exact targets

Your web host may give you one IPv4 address, several IPv4 addresses, an IPv6 address, or a hostname. There is no universal address that works for every host. Cloudflare’s guidance likewise says that the required A, AAAA or CNAME content depends on the provider hosting the website. Copy targets exactly, including a fully qualified hostname and any trailing dot shown by the provider.

Ask the host whether it supports an apex alias (sometimes called an ALIAS, ANAME or CNAME-flattening feature) when it gives you a hostname for the root domain. Standard DNS does not permit a CNAME at a zone apex when other records, including the required SOA and NS records, must coexist there. Use only the apex method your DNS provider documents.

Make an inventory

• Root or apex name, usually entered as @.
• www name and every active subdomain such as blog, shop or app.
• Current MX records and mail-provider TXT, CNAME and other verification records.
• Any domain-verification, analytics, payment, or certificate-validation records.
• DNSSEC status, proxy settings and the existing TTL values.

DNS record types you will use

An A or AAAA value is an address, not a URL: enter only the IP address. A CNAME value is a hostname, not https:// plus a path. The DNS editor may append your domain automatically when a name is entered without a final dot; follow that provider’s documented behavior.

Step-by-step setup for the root domain and www

1. Open the authoritative zone. Sign in to the DNS provider identified by the NS delegation and select the correct domain. If you have just changed nameservers, confirm the new delegation before adding records.
2. Read the hosting instructions. Record the exact IPv4, IPv6 and/or hostname values for the site. Treat illustrative values such as 203.0.113.10, 2001:db8::10 and target.host.example as documentation examples only; never copy them as production destinations.
3. Create the apex record. Enter @ (or leave the name field blank if the interface defines blank as the root). Add the host-prescribed A record, AAAA record, or the provider-supported apex-alias option. If the host supplied both IPv4 and IPv6, add both so clients can use either protocol.
4. Create the www record. Enter www as the name. Use the host’s CNAME target when one is supplied; otherwise use the exact A and/or AAAA address the host specifies. Do not create a CNAME and an A or AAAA record for the same www name.
5. Add only required subdomains. Create blog, shop, app or another label only when a service actually uses it. Point each label to that service’s documented address or hostname.
6. Preserve mail and verification records. Leave existing MX, TXT and service CNAME records in place unless the relevant provider tells you to replace them. Web records and mail records can coexist in one zone; changing one does not require deleting the other.
7. Choose a TTL. Use the host or DNS provider’s recommendation. TTL controls how long recursive resolvers cache an answer and therefore how quickly a change reaches users. A shorter TTL helps during a planned migration but causes more frequent queries; a longer TTL reduces query volume but extends rollback time.
8. Save and verify. Check the authoritative answer, then test through a public resolver and load both the apex and www over HTTPS. Confirm that the returned destination is the one your host supplied and that the server presents a certificate for every advertised hostname.

Choosing A, AAAA or CNAME

Use A for IPv4

An A record is appropriate when the host gives you an IPv4 address. Multiple A records can provide basic distribution or failover only when the host explicitly supports that arrangement; do not add unrelated addresses because a browser may receive any of them.

Rank #2

Sale

DNS & BIND Cookbook

$17.30

Buy on Amazon

Use AAAA for IPv6

An AAAA record is appropriate for an IPv6 address. Add it only when the address is routed to the same website and the host has configured IPv6 correctly. A broken AAAA record can make some visitors fail even while IPv4 testing appears successful, because modern clients may prefer IPv6.

Use CNAME for a hostname

A CNAME is useful when a platform assigns a stable hostname and may change the underlying addresses. It is normally used on a subdomain such as www, not directly at the apex. A CNAME chain used with Cloudflare proxying must ultimately resolve to a hostname that has a valid A or AAAA record. Keep chains short because each additional lookup adds another dependency.

Making the apex and www behavior intentional

The apex (example.com) and www (www.example.com) are different DNS names. If marketing material, search results or links advertise both, publish a working record for both. Cloudflare notes that a www record helps visitors who type the prefixed address reach the site.

After DNS works, choose one canonical URL in your web server or content-management system and redirect the other with a permanent HTTP redirect. DNS cannot redirect a URL or select an HTTPS certificate; it only supplies a destination. Configure TLS certificates for every hostname that should answer, and test both HTTP-to-HTTPS and apex-to-canonical redirects.

Subdomains and separate services

Subdomains let one domain use different infrastructure. For example, blog can point to a publishing platform, app to an application load balancer, and shop to a commerce service. Each service should provide its own target and any verification record. Never assume that the root site’s IP is valid for a new subdomain.

Rank #3

DNS and BIND

$17.96

Buy on Amazon

When a provider asks for a fully qualified CNAME target, enter the complete hostname it gives you. Some dashboards require a final dot to mark an absolute name; others add it automatically. A doubled suffix, such as target.host.example.example.com, is a common result of entering a name in the wrong format.

Keep email working while you change the website

MX records control where incoming mail is delivered. TXT records commonly carry SPF policy and domain-verification strings, while CNAME records are often used for service discovery or verification. Microsoft 365 setup, for example, can require MX, TXT and CNAME records in addition to web records.

• Do not replace MX records with the web host’s address.
• Do not combine an SPF policy with an unrelated verification string in one TXT value; publish separate TXT records as instructed.
• Copy mail-provider priorities and targets exactly.
• After a DNS migration, send a test message in both directions and confirm that existing verification services still pass.

TTL, caching and propagation

TTL is measured in seconds and is attached to each record. Lowering TTL immediately before a change does not instantly clear caches that already hold the previous, longer value. Plan a migration by reducing the TTL in advance, making the change, monitoring it, and raising the TTL again after the new destination is stable.

Microsoft Learn says DNS changes typically take about 15 minutes to take effect, although longer delays occur. That is a typical operational estimate, not a guarantee: recursive resolvers, negative caching, nameserver delegation and provider queues can all extend the wait. Test from more than one network instead of treating one computer’s cached answer as proof of global propagation.

How to verify the result

Query the records directly

Use commands such as dig A example.com, dig AAAA example.com, dig CNAME www.example.com and dig NS example.com. On systems without dig, nslookup example.com provides a basic check. Query a named public resolver when you need to compare caches, for example dig @1.1.1.1 A example.com and dig @8.8.8.8 A example.com; these addresses are resolver endpoints, not values to enter in your zone.

Rank #4

Sale

DNS and BIND on IPv6: DNS for the Next-Generation Internet

• Used Book in Good Condition

$25.79

Buy on Amazon

Check the authoritative answer

First query the nameserver returned by the NS lookup. If it has the new value but a public resolver has the old value, caching is the likely explanation. If the authoritative server has the old value, you edited the wrong zone, the save failed, or the provider has not published the change.

Test the application

• Open https://example.com and https://www.example.com in a private browser window.
• Check redirects, page content, API calls and static assets, not just whether a connection opens.
• Test from an IPv4-only and an IPv6-capable network when an AAAA record exists.
• Confirm that the certificate names include the hostname users enter.

Provider and DNS-service decisions

Choose a DNS provider by capability rather than by a generic speed claim. The important questions are:

Google Cloud’s managed-zone workflow illustrates the basic pattern: create a zone, publish A and/or AAAA records for addresses, and create a CNAME for www when the host supplies a hostname. Cloudflare’s record-management documentation, updated May 6, 2026, emphasizes that TTL determines how long updates remain cached and how quickly users receive them. The exact screens and available apex options vary by provider.

Troubleshooting by symptom

The domain shows DNS_PROBE_FINISHED_NXDOMAIN

NXDOMAIN means the resolver was told that the name does not exist. Check that the registrar’s NS delegation points to the zone you edited, that the zone itself exists, and that the queried hostname has a record. If the apex exists but www does not, add the separate www record. Also check for a recently changed delegation whose old NS data is still cached.

The site opens at one name but not the other

Inspect A, AAAA and CNAME records for both names. A working apex record does not automatically create www, and a working CNAME for www does not create the apex. Add the missing record and configure the corresponding web-server virtual host and certificate.

Best Value

Sale

DNS and BIND, Fourth Edition

• Used Book in Good Condition

$37.46

Buy on Amazon

The old site still appears

Compare the authoritative answer with answers from several recursive resolvers. If only recursive results are old, wait for the prior TTL to expire. If the authoritative answer is old, correct the zone, check that the record is enabled, and confirm that you saved the change in the active DNS provider.

Some users fail while others succeed

Look for conflicting A records, an incorrect AAAA record, round-robin behavior or resolver-specific caching. Temporarily remove an unneeded address only after confirming with the host; do not hide a broken IPv6 path by guessing.

A CNAME is rejected or loops

Check whether another record already exists at that name. A CNAME cannot share a name with A, AAAA, MX or TXT records. Follow each CNAME hop until it reaches a hostname with a valid A or AAAA answer, and remove accidental self-references or circular aliases.

Email stopped after the website change

Compare MX and TXT records with the email provider’s current instructions. Restore deleted MX targets and verification TXT values, then allow their TTLs to expire. A web host’s A record should never replace mail-provider MX records.

Security and maintenance checks

• Enable DNSSEC when your registrar and DNS provider support it, and keep the DS record synchronized during a provider migration. An incorrect DS record can make the entire domain appear unavailable to validating resolvers.
• Restrict DNS-account access, require multifactor authentication, and review change logs after every edit.
• Remove stale verification, test and abandoned-subdomain records. An unused CNAME can become a dangling alias if the target service is released.
• Document the owner, purpose, target, TTL and renewal date for every non-obvious record.
• Export or record the zone before changing nameservers so you can restore mail and verification data quickly.

Migration checklist

1. Lower TTLs ahead of the planned cutover, subject to the current cached values.
2. Export the existing zone and inventory A, AAAA, CNAME, MX, TXT, NS and DNSSEC-related data.
3. Create the complete equivalent zone at the new DNS provider.
4. Check the new provider’s authoritative nameservers directly for the apex, www, mail and verification names.
5. Change NS delegation at the registrar to the new provider’s exact nameservers.
6. Monitor answers from multiple networks and test website, HTTPS, subdomains and email.
7. Keep the old zone available until caches have expired and all services are confirmed, then raise TTLs and remove the obsolete service.

Practical example (illustrative values only)

Suppose a host instructs you to use an IPv4 address, an IPv6 address and a hostname for www. In the DNS editor, the finished shape would be:

Replace every example value with the host’s current instructions. The table demonstrates record shape, not a destination that will serve a real website.

When the setup is complete

A correct configuration has an authoritative NS delegation, host-approved records for every advertised web name, no conflicting records, intact MX and TXT data, and a tested HTTPS response. Record the final values and the date of the change so the next migration or troubleshooting session starts with an accurate map of the zone.

Quick Recap

SaleBestseller No. 1

DNS and BIND (5th Edition)

$38.88

SaleBestseller No. 2

DNS & BIND Cookbook

$17.30

Bestseller No. 3

DNS and BIND

$17.96

SaleBestseller No. 4

DNS and BIND on IPv6: DNS for the Next-Generation Internet

Used Book in Good Condition

$25.79

SaleBestseller No. 5

DNS and BIND, Fourth Edition

Used Book in Good Condition

$37.46

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.