About Contact Privacy Policy Disclaimer Terms
Home / Hosting / Article

DNS Configuration Best Practices: Fixing CNAME, A Records, and SSL Mismatches on Custom Domains

Author Digital Bhatti
• August 22, 2026 • Hosting

Connecting a custom domain to your website or blog is one of the first foundational steps in building an established brand identity. However, misconfigured Domain Name System (DNS) records frequently lead to domain downtime, unresolved URL paths, search crawler disconnections, and browser security warnings like "SSL Certificate Name Mismatch" or "DNS_PROBE_FINISHED_NXDOMAIN".

Understanding how A Records, CNAME Records, and Apex 301 Redirects interact is crucial for maintaining seamless domain availability and fast global routing. In this technical walkthrough, we break down standard DNS record types, provide exact configuration tables, and explain how to resolve common SSL handshake and propagation issues.

1. Understanding Core DNS Record Types

DNS acts as the internet's phonebook, translating human-friendly domain names (e.g., digitalbhatti.com) into machine-readable IP addresses:

Record Type Full Name Function Target Value Example
A Address Record Points an apex domain or subdomain directly to an IPv4 address 216.239.32.21
AAAA IPv6 Address Record Points a domain directly to a modern 128-bit IPv6 address 2001:4860:4802:32::15
CNAME Canonical Name Aliases one domain/subdomain name to another host domain ghs.google.com
TXT Text Record Holds text metadata for domain ownership verification (Google, SSL, SPF) google-site-verification=...

2. Standard Custom Domain DNS Configuration

To ensure your root domain (e.g., digitalbhatti.com) properly forwards to your primary subdomain (e.g., www.digitalbhatti.com) without SSL warnings, configure the standard four Google A-records and two CNAME records:

A. Four Google Anycast A-Records (Root Apex Domain)

Add the following four A-records pointing your root domain (@) to Google's load balancers:

  • Host: @ (or blank)  |  Points to: 216.239.32.21  |  TTL: 3600
  • Host: @ (or blank)  |  Points to: 216.239.34.21  |  TTL: 3600
  • Host: @ (or blank)  |  Points to: 216.239.36.21  |  TTL: 3600
  • Host: @ (or blank)  |  Points to: 216.239.38.21  |  TTL: 3600

B. Required CNAME Records

  1. Public Routing CNAME:
    • Host Name: www
    • Target Destination: ghs.google.com
  2. Security Verification CNAME:
    • Host Name: Unique 12-character token generated in your Blogger dashboard (e.g., gv-xxxxxx).
    • Target Destination: Unique Google verification endpoint (e.g., gv-xxxxxx.dv.googlehosted.com).

3. Enforcing Canonical Apex-to-WWW Redirection

Running both http://yourdomain.com and http://www.yourdomain.com simultaneously as separate endpoints splits link equity and causes duplicate content indexing issues in Google Search.

How to Set Up 301 Canonical Redirects in Blogger:

  1. In the Blogger Dashboard, navigate to Settings > Publishing > Custom domain.
  2. Ensure your domain is saved as www.yourdomain.com.
  3. Turn ON the toggle for Redirect domain (Redirects yourdomain.com to www.yourdomain.com).
  4. Under the HTTPS section:
    • Enable HTTPS availability.
    • Enable HTTPS redirect (Forces all HTTP requests to encrypted HTTPS).

4. Troubleshooting Common DNS and SSL Errors

A. "DNS_PROBE_FINISHED_NXDOMAIN"

Cause: The domain does not exist in public DNS resolvers, or the registrar’s nameservers are pointing to an inactive DNS zone.
Solution: Verify that your domain registrar's active nameservers match your DNS provider, and verify that the A and CNAME records are published without typos.

B. "SSL Certificate Name Mismatch" (ERR_CERT_COMMON_NAME_INVALID)

Cause: The browser connected to an IP server hosting an SSL certificate issued for a different domain name, or the certificate has not finished provisioning for both www and non-www variants.
Solution: In Blogger Settings, toggle HTTPS availability OFF, wait 10 minutes, and toggle it back ON to trigger a fresh certificate issuance from Let's Encrypt / Google Trust Services.

C. Stale DNS Caching (High TTL Latency)

Cause: When modifying DNS records, old settings remain cached locally based on the record's Time to Live (TTL) value.
Solution: Flush your local DNS resolver cache:

# Windows Command Prompt:
ipconfig /flushdns

# macOS Terminal:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

5. Verifying DNS Propagation Using Terminal Commands

Use standard diagnostic command-line utilities to inspect live DNS records globally:

  • Check A Records: 
    dig yourdomain.com +short A
  • Check CNAME Records: 
    nslookup -type=CNAME www.yourdomain.com
  • Trace Complete DNS Delegation: 
    dig yourdomain.com +trace

Summary: DNS Configuration Checklist

  • Configure all 4 Google A-records on the root apex domain.
  • Map the www CNAME record to ghs.google.com.
  • Add the unique security token CNAME for ownership verification.
  • Enable automatic 301 apex-to-www redirection.
  • Activate HTTPS availability and enforce HTTPS redirects.
  • Verify global propagation using dig or online DNS lookup tools.