DNS Configuration Guide: A, CNAME, MX, TXT, TTL & Troubleshooting

DNS configuration determines which server, mail system, verification service, or certificate authority your domain connects to. Most DNS failures come from a wrong target, a conflicting record, stale cached data, or a delegation/security problem rather than from “DNS being slow.”

For a normal website, the practical order is:

1. Confirm the authoritative nameservers
2. Check A / AAAA / CNAME for the hostname
3. Verify apex and www separately
4. Preserve MX and TXT records during web-hosting changes
5. Check TTL and resolver caches
6. Verify DNSSEC / DS when nameservers change
7. Test the final public answer from multiple resolvers

• Send each hostname to the correct destination.
• Keep email and verification records intact.
• Reduce migration risk.
• Protect the DNS account and signing chain.
• Make troubleshooting predictable.

Last verified: September 20, 2026. DNS provider behavior, TTL limits, proxy features and migration guidance can change; verify current provider documentation before making production changes.

---

---

DNS settings are only one part of a hosting decision. For infrastructure, renewal, support and migration considerations, use the Web Hosting Buyer Guide.

DNS Migration Checklist

If you are moving hosting without changing public URLs, DNS is primarily an infrastructure cutover task. It is not automatically a redirect or canonicalization project.

1. Inventory the current zone. Export or record A, AAAA, CNAME, MX, TXT and verification records before making changes.
2. Prepare the destination first. Confirm the new server, CDN or hosting endpoint is ready before DNS is switched.
3. Lower TTL in advance when practical. This can reduce how long older cached answers remain in circulation during a planned cutover.
4. Change only the records required for the move. Do not accidentally replace unrelated mail or verification records.
5. Verify authoritative and recursive answers. Check what the authoritative nameservers return and what public resolvers are seeing.
6. Test the website over HTTPS. Confirm the destination has the correct certificate and serves the expected host.
7. Monitor after the change. Watch origin logs, uptime and Search Console for crawl problems.

If the migration also changes URLs or domains, use the Redirects & Site Migrations Guide for URL mapping and permanent redirects. Google recommends changing one major thing at a time where practical, updating internal links and sitemaps, and monitoring the move in Search Console.

---

Practical DNS Record Examples

These examples show the role of common records. Replace every placeholder with the values supplied by your host, email provider, CDN or verification service.

---

1. DNS Record Types You Need to Understand

---

2. A Records: Point a Hostname to IPv4

An A record maps a hostname to an IPv4 address.

Example:

Type: A
Name: @
Value: 192.0.2.10

Use the IP address supplied by the current hosting or infrastructure provider.

Do not guess the address from an old tutorial or another customer's setup.

---

3. AAAA Records: IPv6 Must Actually Work

AAAA records map hostnames to IPv6 addresses.

If you publish both A and AAAA records, test both paths.

A broken AAAA record can create confusing behavior where some visitors reach the site and others experience connection failures or delays.

If the server does not support IPv6 for that hostname, do not publish an arbitrary AAAA record.

---

4. CNAME Records: Alias One Hostname to Another

A CNAME maps one hostname to another hostname.

Type: CNAME
Name: www
Target: example-host.provider.net

Cloudflare's current DNS record-type documentation defines CNAME as an alias from one hostname to another hostname. The target ultimately needs resolvable address information for web traffic.

Common problems include:

• Pointing to the wrong target.
• Leaving an old A record at the same hostname.
• Creating a CNAME loop.
• Changing proxy status without understanding the impact.

---

5. Apex CNAMEs and CNAME Flattening

Traditional DNS rules make the zone apex special because the root name also needs records such as SOA and NS.

Some DNS providers solve this operational problem with features such as CNAME flattening or ALIAS/ANAME-style behavior.

Cloudflare, for example, supports CNAME flattening.

Use the method supported by your DNS provider instead of blindly creating an apex CNAME from instructions written for a different platform.

---

6. Apex vs www: Configure and Test Them Separately

The root domain (example.com) and www.example.com are different hostnames. They can use different DNS record types and still need the web server or CDN to serve or redirect them consistently.

example.com      → A/AAAA or provider-supported apex alias/flattening
www.example.com  → CNAME to the intended hostname

Do not assume that fixing one hostname fixes the other. Test both DNS resolution and HTTPS behavior separately.

---

7. MX Records: Do Not Break Email During a Hosting Move

Website hosting and email hosting may be provided by different companies.

Changing the web server does not automatically mean the MX records should change.

Before editing DNS, identify:

• Current mail provider.
• Current MX priorities.
• SPF TXT record.
• DKIM records/selectors.
• DMARC policy.

A common migration mistake is replacing the whole DNS zone and accidentally deleting mail records that were already correct.

---

8. TXT Records: Verification and Email Authentication

TXT records are used for many services, including:

• Search Console domain verification.
• SPF.
• DKIM.
• DMARC.
• Certificate DNS challenges.
• Third-party service verification.

Do not delete unfamiliar TXT records until you know what service created them.

---

9. Search Console Domain Verification with TXT Records

Google Search Console domain properties commonly use a DNS TXT verification record. Add the exact token Google provides at the DNS provider that is authoritative for the domain.

Before removing a TXT record that looks unfamiliar, check whether it belongs to Search Console, your mail provider, a certificate validation process or another service. Removing a verification record can break ownership verification even when the website itself keeps working.

---

10. SPF, DKIM and DMARC

Email authentication is part of DNS hygiene.

At a high level:

• SPF identifies systems permitted to send mail for a domain.
• DKIM uses signed messages and a public DNS key.
• DMARC defines policy and reporting based on SPF/DKIM alignment.

Use the exact records generated by your mail provider. Do not paste another company's SPF or DKIM values into your domain. For deeper implementation, use the SPF, DKIM & DMARC guide.

---

11. CAA Records and SSL Certificate Issuance

CAA records specify which certificate authorities are allowed to issue certificates for a domain.

They are useful when you want explicit control over certificate issuance.

They can also cause failed issuance when a restrictive CAA policy does not permit the CA your hosting or certificate vendor uses.

If you are choosing between free, wildcard, multi-domain, OV or EV certificates rather than troubleshooting DNS validation, use our Best SSL Certificates guide.

---

12. TTL: What It Actually Controls

TTL—Time to Live—controls how long recursive DNS resolvers are allowed to cache a DNS answer before revalidating it.

Longer TTLs can increase cache reuse.

Shorter TTLs can make planned record changes visible sooner after cached answers expire.

Cloudflare's current TTL documentation states that proxied records use Auto TTL at 300 seconds. DNS-only records can use configurable TTL values within the provider and plan limits. A local or ISP cache can still make a change appear to take longer than the record TTL.

---

13. Do Not Use 300 Seconds as a Universal TTL

A five-minute TTL can be useful during a migration, but it is not automatically the best permanent setting for every record.

A sensible workflow is:

Before planned migration:
Lower TTL in advance

During migration:
Change target record
Monitor old + new infrastructure

After migration is stable:
Raise TTL to normal production value if appropriate

Google Search Central recommends lowering DNS TTL to a conservative low value before a hosting migration—its current example is a few hours, at least a week in advance—so cached answers can refresh faster during the cutover.

---

14. DNS Propagation, Resolver Caching and Delegation

After a DNS change, different resolvers may continue returning the old value until their cached answer expires.

There can also be:

• Local operating-system caches.
• Browser caches.
• ISP/recursive resolver caches.
• Nameserver delegation changes.

That is why two users can temporarily see different answers after a change.

---

15. DNS and TTFB

DNS lookup can contribute to the startup time of a navigation when the hostname is not already cached.

But DNS is only one part of browser-observed TTFB.

Connection setup, TLS, network latency, CDN behavior, server queueing, PHP execution, database queries and external APIs can also matter.

For the complete request-path diagnosis, use our TTFB Optimization Guide.

---

16. DNSSEC

DNSSEC adds cryptographic validation to DNS responses so resolvers can verify that signed DNS data has not been altered in transit.

DNSSEC must be configured consistently between the authoritative DNS provider and the parent-zone delegation.

A bad DS record can make a domain fail validation entirely.

Do not enable or migrate DNSSEC casually without understanding where DNSKEY signing and the parent-zone DS record are managed. Some providers support advanced active or multi-signer migrations, but a standard migration still needs a provider-specific plan to avoid a broken validation chain.

---

17. Secure the DNS and Registrar Accounts

DNS security starts with account security.

Protect:

• Domain registrar account.
• DNS provider account.
• Email account used for password recovery.
• Cloud/CDN account.

Use MFA where available, remove old administrator access, and document who controls the domain.

For the broader security stack, use the Website Security Checklist.

---

18. Cloudflare Proxy Status: Proxied vs DNS Only

Cloudflare currently allows only A, AAAA and CNAME records used for IP address resolution to be proxied.

MX and TXT records are not proxied. Domain-verification CNAMEs should remain DNS-only when the verification service expects the real CNAME target.

Do not toggle proxy status as a generic troubleshooting step. Changing it can expose the origin IP and remove Cloudflare proxy protections for that hostname.

---

19. Common DNS Error: Website Still Opens the Old Server

Check:

1. The current authoritative nameservers.
2. The A/AAAA/CNAME answer for the hostname.
3. Whether a proxy/CDN is involved.
4. Whether the old IP is still published anywhere.
5. Whether local/resolver cache is returning an earlier answer.

Do not shut down the old server immediately after changing DNS during an important migration.

If Cloudflare is in front of the site and the origin connection is being refused after a DNS/origin change, use the Cloudflare Error 521 guide for origin/firewall diagnostics rather than treating it as a general DNS propagation issue.

---

20. Common DNS Error: www Works but Apex Does Not

This usually means the two hostnames are configured differently.

Check:

• example.com
• www.example.com

Each hostname must resolve correctly, and your web server/CDN must also be configured to serve or redirect it appropriately.

---

21. Common DNS Error: SSL Certificate Will Not Issue

Check:

• Does the hostname resolve to the expected server?
• Is the CA permitted by existing CAA records?
• Is the ACME HTTP/DNS challenge reachable?
• Is a proxy interfering with the validation method?
• Are old IPv6 records sending validation to a different server?

For certificate deployment across multiple hostnames, use the multi-domain and wildcard SSL guide.

---

22. Common DNS Error: Email Stops After Migration

Check MX and TXT records before changing anything else.

If web hosting changed but email did not, the mail records often should remain exactly as they were.

Compare the current zone with the export or screenshot taken before the migration.

---

23. Hosting Migration DNS Workflow

Google Search Central's current hosting-migration guidance recommends preparing the new infrastructure first, then updating DNS and monitoring both old and new servers while caches change.

1. Build and test new hosting
2. Preserve Search Console verification
3. Lower TTL in advance if useful
4. Change only required DNS records
5. Monitor old + new server logs
6. Check public DNS answers
7. Keep old hosting online until traffic reaches zero
8. Restore normal TTL after stabilization

For the infrastructure trade-offs behind a move, read our Shared vs VPS vs Cloud Hosting Guide.

---

24. Domain Migration vs Hosting Migration

These are different projects.

Hosting migration

The public URLs stay the same. DNS changes send the same hostnames to new infrastructure.

Domain migration

The visible URLs change from one domain/subdomain to another. DNS is only one part of the migration; redirects, canonicals, sitemaps and Search Console also matter.

Do not treat a domain move as "just change the A record."

If Google is selecting the wrong preferred URL after a domain or URL change, diagnose that separately in the Canonical URLs & rel=canonical Guide. DNS does not choose the canonical URL.

---

25. Blogger Custom Domain Troubleshooting

For Blogger custom domains, use the exact CNAME/A records currently shown by Blogger or Google's setup instructions for your account.

Do not rely on stale screenshots from an old tutorial if Blogger presents different verification values.

After DNS is correct, also confirm:

• The custom domain is saved in Blogger.
• HTTPS availability is enabled.
• HTTPS redirect is enabled after the certificate becomes available.
• www/non-www behavior matches the intended canonical host.

---

26. NXDOMAIN, SERVFAIL and Other DNS Failure States

Do not treat these states as interchangeable. NXDOMAIN is different from SERVFAIL, and both are different from receiving a valid but stale or incorrect answer.

---

27. Useful DNS Diagnostic Commands

Separate authoritative DNS from recursive resolver output when diagnosing a change. An authoritative nameserver tells you what the zone currently publishes; a recursive resolver tells you what that resolver currently knows or still has cached.

On systems with dig:

dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com TXT
dig example.com CAA
dig example.com NS
dig +trace example.com

# Alternatives when dig is unavailable
nslookup example.com
host example.com

Use the output to verify authoritative answers rather than assuming the dashboard value is what the public internet is currently receiving.

To see the delegation and then query an authoritative server directly:

dig example.com NS
dig @ns1.example-dns.com example.com A

Replace the nameserver with one actually returned for the domain.

---

28. How to Compare DNS Answers From Multiple Resolvers

You can query known recursive resolvers directly:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Different answers immediately after a change usually point to caching, delegation or configuration differences that need investigation.

---

29. DNS Configuration Checklist

• Confirm authoritative nameservers.
• Export or screenshot the zone before edits.
• Verify A and AAAA records.
• Verify www and apex separately.
• Preserve MX records during web-hosting moves.
• Preserve required TXT verification records.
• Check SPF, DKIM and DMARC.
• Review CAA before certificate issuance.
• Plan TTL before migrations.
• Check DNSSEC/DS records when changing DNS providers.
• Use MFA on registrar and DNS accounts.
• Monitor old/new infrastructure during migrations.

---

30. Common DNS Configuration Mistakes

• Deleting the whole zone during a simple server move.
• Leaving a stale AAAA record.
• Changing MX records when email is not moving.
• Publishing restrictive CAA without permitting the active CA.
• Expecting every DNS change to appear everywhere immediately.
• Using extremely low TTL forever without a reason.
• Shutting down the old server too soon.
• Assuming DNS alone explains high TTFB.
• Copying provider-specific records from someone else's account.
• Breaking DNSSEC during a nameserver migration.

---

31. Final DNS Decision Framework

Website not resolving?
   ↓
Check NS → A/AAAA/CNAME → proxy/CDN

Email broken?
   ↓
Check MX → SPF/DKIM/DMARC

SSL issuance failing?
   ↓
Check A/AAAA → CAA → validation path

Migration in progress?
   ↓
Check TTL → old/new servers → public resolver answers

DNS looks correct but site is slow?
   ↓
Move to full TTFB / application diagnosis

Good DNS operations are mostly about controlled changes, preserving unrelated records, and verifying the public result before declaring the migration complete.

---

Frequently Asked Questions

What does NXDOMAIN mean?

NXDOMAIN means the queried DNS name does not exist according to the resolver's result. Check the hostname spelling, record presence, authoritative zone and delegation.

What does SERVFAIL mean?

SERVFAIL means the resolver could not complete resolution successfully. DNSSEC/DS problems, broken delegation or authoritative-server failures are common places to investigate.

Should example.com and www.example.com use the same DNS record?

Not necessarily. They are separate hostnames and may use different record types, but both must resolve correctly and your web server or CDN should serve or redirect them consistently.

What is the difference between an A record and a CNAME?

An A record maps a hostname directly to an IPv4 address. A CNAME maps one hostname to another hostname.

Do I need an AAAA record?

Only publish an AAAA record when the destination supports IPv6 correctly. A broken IPv6 route can cause failures even when IPv4 works.

What TTL should I use?

There is no universal value. Lower TTL can be useful before planned migrations, while a longer production TTL can increase cache reuse. Use the range supported by your DNS provider and the needs of the record.

How long does DNS propagation take?

There is no one fixed global time. Existing resolver caches generally continue using the previous answer until its TTL expires, and nameserver/delegation changes can involve additional caching.

Can DNS affect TTFB?

Yes, DNS lookup can contribute to startup latency when a lookup is required. It is only one part of TTFB, which can also include connection, TLS, network, CDN and backend processing.

Can a wrong CAA record break SSL?

Yes. Restrictive CAA records can prevent a certificate authority from issuing a certificate when that CA is not permitted.

Should I change MX records when changing web hosts?

Not unless your email provider is also changing. Web hosting and mail hosting are often separate services.

Should I disable DNSSEC before changing DNS providers?

Follow the migration process of your registrar and DNS provider carefully. An incorrect DS record during a DNSSEC migration can make the domain fail validation.

What should I back up before editing DNS?

Export the zone if your provider supports it, or at minimum record all A, AAAA, CNAME, MX, TXT, CAA and other important records before changing anything.