How to Set Up the Right DNS Records for Your Website

To point a domain at a website, edit the DNS zone published by the domain’s authoritative nameservers—not necessarily the registrar where you bought the domain. Get the exact IPv4, IPv6, or hostname targets from your web host, create the required record for the root domain, add a separate record for www if you use it, and leave mail records intact. After saving, verify both hostnames and allow cached DNS answers to expire.

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

The correct records depend on your host, DNS provider, and whether the name is the zone apex or a subdomain. There is no universal IP address to copy. The workflow below shows how to choose each record, avoid conflicts, and diagnose a site that still does not resolve.

#	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.

Understand who controls your DNS

Three services are often confused:

• Registrar: the company that registers your domain and lets you change its nameserver delegation.
• Authoritative DNS provider: the service whose nameservers publish the DNS zone containing your A, AAAA, CNAME, MX, and TXT records.
• Web host: the service that supplies the destination address or hostname where the site runs.

Editing records at the registrar works only when the registrar is also authoritative for the domain. Check the domain’s current NS delegation first. If the NS values point to another DNS service, make changes in that service’s zone editor.

When a provider such as Cloudflare is authoritative

If you want Cloudflare to manage the zone, add the domain there and use the nameservers supplied for that zone. Then replace the registrar’s existing nameservers with those assigned values. Records entered in Cloudflare do not become authoritative until the delegation points to Cloudflare’s nameservers. Changing nameservers is separate from adding an A or CNAME record.

#1 Best Overall

Sale

DNS and BIND (5th Edition)

$38.88

Buy on Amazon

Collect the exact values from your web host

Before opening a DNS editor, find the host’s domain-connection instructions. The host may give you:

• An IPv4 address for an A record.
• An IPv6 address for an AAAA record.
• A fully qualified hostname for a CNAME record.
• Separate destinations for the root domain and www.
• A special apex-alias method supported by your DNS provider.

Copy the target exactly. Do not substitute an address found in a tutorial or guess from another customer’s setup. Hosting platforms can use different addresses by region, plan, load-balancing configuration, or account. If the instructions show a fully qualified name with a trailing dot, preserve the provider’s required format; some editors add the dot automatically.

DNS record types you may need

An A or AAAA record is an address record. A CNAME is an alias and must point to a hostname, not an IP address. MX and TXT records serve email and verification rather than ordinary web traffic. NS delegation determines which service publishes all of them.

Set up the root domain and www

The following procedure applies in most DNS dashboards. Labels vary, but the fields are generally name, type, target or content, and TTL.

1. Open the authoritative zone. Confirm that the domain appears in the DNS provider where the NS delegation currently points.
2. Back up or note existing records. Especially record MX, TXT, existing A or AAAA records, and any records used by subdomains or verification services.
3. Create the apex record. In the name field, choose the provider’s root notation, commonly @ or a blank name. Add the host-prescribed A record for IPv4 and/or AAAA record for IPv6. If the host gives a supported apex hostname instead of an address, use the provider’s documented apex-alias feature rather than placing a CNAME at the apex when that is not allowed.
4. Create the www record. Enter www as the name. Use the host-prescribed CNAME target when one is supplied, or use the address record the host explicitly requires. A CNAME target should be a fully qualified hostname, such as the host’s documented service name.
5. Add only the subdomains you use. For example, create blog, shop, or app only when those services exist. Point each one to its own documented IPv4, IPv6, or hostname target.
6. Save and review the resulting zone. Check that the dashboard did not append the domain twice to a CNAME target, convert the name unexpectedly, or create duplicate records.

Why the apex and www records are separate

The root name and www are different hostnames. A visitor entering example.com queries the apex; a visitor entering www.example.com queries the www label. If both URLs are advertised, both must resolve. A working apex record does not automatically create a working www record.

Cloudflare-proxied CNAME chains

When Cloudflare proxying is enabled, a CNAME chain must ultimately resolve to a hostname that has a valid A or AAAA record. If the final hostname has no address record, the chain cannot lead visitors to the site. Check the complete chain at the host and DNS provider rather than testing only the first alias.

Rank #2

Sale

DNS & BIND Cookbook

$17.30

Buy on Amazon

Keep email records separate from website records

Changing web records should not require deleting mail records. MX records tell other servers where to deliver mail, while TXT records can prove domain ownership or publish SPF-related policy. Email platforms may also require CNAME records for service discovery or verification.

Before replacing an existing zone, preserve every MX and TXT value that belongs to your mail provider. If you move DNS providers, recreate those records in the new zone before changing nameservers. A website can load normally while mail is broken, so test both services after a DNS migration.

Choosing A, AAAA, or CNAME

Use A for an IPv4 destination

Choose A when the host gives an IPv4 address and expects the hostname to resolve directly to it. The apex commonly uses this arrangement. Enter only the address in the target field; do not prefix it with a protocol such as https://.

Use AAAA for an IPv6 destination

Choose AAAA when the host supplies an IPv6 address. You can publish A and AAAA together when the host supports both address families. Visitors with IPv6 connectivity may prefer the AAAA answer, so an incorrect IPv6 record can make a site appear broken even when its IPv4 record is correct.

Use CNAME for a hostname destination

Choose CNAME when the provider gives a hostname rather than an IP address, commonly for www or a service subdomain. A CNAME cannot share the same name with other A, AAAA, MX, or another CNAME records in a standard zone. Remove a conflicting record only after confirming that it is not used by another service.

Handle the apex limitation carefully

Traditional DNS does not permit a CNAME at the zone apex because the apex already has required zone records such as SOA and NS. Some providers offer an alias, flattened CNAME, or equivalent apex feature. Use it only when both the DNS provider and the host support that method. Otherwise use the host’s A and/or AAAA values for the root and reserve CNAME for a subdomain.

Rank #3

DNS and BIND

$17.96

Buy on Amazon

Set a sensible TTL

TTL means time to live. It tells recursive resolvers how long they may cache an answer before asking the authoritative server again. A shorter TTL can make a planned change visible sooner after caches expire; a longer TTL reduces repeat queries but can keep an old destination cached for longer.

Follow the DNS provider’s or host’s recommendation. Lower the TTL before a planned migration when the provider advises doing so, make the change, then raise it again after the new destination is stable. TTL does not force every resolver to refresh immediately: resolvers may still hold an earlier answer until its previous TTL expires.

How long DNS changes take

Microsoft’s DNS guidance says changes typically take about 15 minutes to take effect, although longer delays occur. The actual wait depends on the previous TTL, resolver caches, nameserver delegation, and whether you changed records or nameservers. A nameserver change can involve more layers of caching than editing one record.

Do not repeatedly edit a record while waiting. First confirm that the authoritative zone contains the intended value, then allow the relevant cache period to pass. Testing from a second network or a public resolver can help distinguish a local cache from an authoritative configuration error, but a cached result alone is not proof that the zone is wrong.

Verify the configuration

1. Query the apex. Look up the A and AAAA answers for the root domain and confirm they match the host’s instructions.
2. Query www. Check whether www returns the expected CNAME or address record.
3. Follow aliases. If www is a CNAME, resolve its target and confirm that the final hostname has a valid A or AAAA answer.
4. Load both URLs. Test the apex and www in a browser, including the HTTPS version if your host has configured TLS for both names.
5. Check mail separately. Query MX and relevant TXT records if the domain handles email.

Google’s DNS setup guidance recommends confirming that the domain resolves to the intended IP address. A successful DNS answer does not guarantee that the web server is configured for the domain, so an HTTP error after correct resolution may require a host-side domain or certificate fix.

Common failures and precise fixes

The DNS editor shows the right value, but the public lookup shows something else

Check the domain’s NS delegation at the registrar. You may be editing a secondary or inactive zone while another provider remains authoritative. Change records in the service named by the NS records, or complete the nameserver change if you intend to move authority.

Rank #4

Sale

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

• Used Book in Good Condition

$25.79

Buy on Amazon

The domain returns DNS_PROBE_FINISHED_NXDOMAIN

NXDOMAIN means the queried name does not exist from the resolver’s perspective. Confirm that the zone exists at the authoritative provider, that the apex or requested subdomain record was created with the correct name, and that the NS delegation points to the intended zone. An incomplete zone or a typo in the hostname can produce this result.

www works but the root domain does not

The two names need separate records. Add the host-prescribed A and/or AAAA record, or the supported apex-alias configuration, for the root name. Do not assume a www CNAME covers the apex.

The root works but www does not

Check for a www record and verify its target character for character. If the host supplied a CNAME, make sure the editor did not turn the target into a relative name or append the domain twice. If you advertise www, keep that record even when the apex already resolves.

One network reaches the old site

Compare the record’s current TTL with the time since the change. A resolver may still have the old answer cached. Check the authoritative answer and wait for caches to expire before making another edit.

Some visitors fail while others succeed

Look for conflicting A and AAAA records. An incorrect AAAA answer can affect IPv6 users while IPv4 users reach the correct A address. Remove or correct only the value confirmed to be wrong by the host, and ensure every published address belongs to the same intended service.

Email stopped after a website change

Review MX and TXT records first. Do not replace mail records with web targets. If nameservers were changed, recreate all mail-provider records in the new authoritative zone and verify them independently.

Best Value

Sale

DNS and BIND, Fourth Edition

• Used Book in Good Condition

$37.46

Buy on Amazon

A CNAME will not save

Look for another record with the same hostname. A CNAME generally cannot coexist with A, AAAA, MX, or another CNAME at that name. Also confirm that the target is a hostname, not an IP address, and that the provider allows CNAME use at that position.

Compare DNS providers by capabilities, not branding

When selecting or moving DNS providers, evaluate the features that affect this setup:

• Record support: A, AAAA, CNAME, MX, TXT, NS, and any apex-alias behavior required by your host.
• TTL control: whether you can set the values recommended for a migration or routine operation.
• Proxying: whether the service can proxy web traffic and what that changes about address visibility, CNAME chains, and troubleshooting.
• DNSSEC controls: whether the provider supports signing and gives you a safe way to manage delegation changes.
• Registrar integration: how clearly it presents nameserver assignments and delegation status.
• Diagnostics: authoritative answers, change history, validation, and tools that expose conflicting or malformed records.
• Support and cost: the level of assistance and pricing appropriate for the domain’s importance.

Cloudflare and Google Cloud DNS both publish setup documentation, but the deciding factor is whether the service supports the exact targets and apex behavior required by your host. A provider with many features is not automatically the right choice if its editor obscures delegation or makes the required record type unavailable.

Safe example values for learning

The following are documentation-only examples, not destinations to copy into a live zone:

• 203.0.113.10 represents an example IPv4 address for an A record.
• 2001:db8::10 represents an example IPv6 address for an AAAA record.
• target.host.example represents an example fully qualified CNAME target.

Replace these examples with the exact values supplied for your domain. The correct record name might be @, a blank field, or the full domain depending on the dashboard; follow that provider’s label conventions and inspect the saved result.

A practical pre-change and post-change checklist

Before editing

• Identify the authoritative nameservers from the domain’s NS delegation.
• Sign in to that DNS provider, not merely the registrar.
• Obtain current A, AAAA, and CNAME targets from the web host.
• Record existing MX, TXT, and service-verification entries.
• Decide whether the root and www names will both be advertised.

After saving

• Confirm the apex record uses the host’s prescribed address or supported alias method.
• Confirm www has its own correct record.
• Check that no hostname has conflicting address and CNAME records.
• Resolve the final destination of every CNAME chain.
• Allow TTL and nameserver caches time to expire.
• Test the apex, www, and email records separately.

DNS setup is correct when the authoritative zone contains the host’s exact targets, the intended nameserver delegation publishes that zone, both advertised web hostnames resolve, and mail records remain unchanged and functional.

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.