How to Verify DNS After Deploying Your App to the Cloud

You have built your app, deployed it, and pointed your custom domain to it. But the site is not loading or worse, it works on your machine but not for your users. Nine times out of ten, the problem is DNS.

DNS configuration is one of the most overlooked steps in app deployment. Get it wrong, and your site is down, your SSL certificate fails, or half the world sees the old version while the other half sees the new one. Here is how to verify everything is working correctly after deployment.

Why DNS Matters During Deployment

When you deploy an app and assign a custom domain, you are telling the internet where to find your application. This involves creating DNS records that map your domain name to your hosting provider’s servers.

The problem is that DNS changes do not take effect instantly. DNS propagation, the process of your updated DNS records spreading across DNS servers worldwide, can take anywhere from a few minutes to 48 hours depending on your TTL (Time to Live) settings and the DNS servers involved.

During this window, some users reach your new server while others still hit the old one. If you are migrating from one host to another, this means some visitors see your app and others see a dead page or the previous version.

Understanding how DNS propagation works and knowing how to verify it saves you from unnecessary downtime and last minute troubleshooting.

A Record vs CNAME: Which One to Use

This is where most deployment DNS mistakes start. Your hosting provider tells you to add a DNS record, but which type?

Use an A record when:

• You are pointing your root domain (example.com) to the server
• Your provider gives you an IP address
• You need other DNS records like MX (email) on the same hostname

Use a CNAME when:

• You are pointing a subdomain (www.example.com, app.example.com) to the server
• Your provider gives you a hostname (like cname.vercel-dns.com)
• The provider’s IP address may change without notice

The most common mistake: Adding a CNAME on your root domain. Standard DNS does not allow a CNAME record to coexist with other record types on the same hostname. Since root domains need NS and SOA records, adding a CNAME there breaks things. Some DNS providers offer workarounds (Cloudflare calls it CNAME flattening), but if your provider does not support this, use an A record for the root domain and a CNAME for www or other subdomains.

If you are unsure which records are currently set, you can check them using an online DNS lookup tool to see what is currently resolving globally.

Checking Propagation Globally

Here is something that catches even experienced developers: your DNS change looks correct on your machine, but it is not working for everyone else.

This happens because your local machine, your ISP, and your browser all cache DNS responses. When you update a record, your local cache may still hold the old value. Running nslookup example.com on your machine tells you what your local resolver sees, not what the rest of the world sees.

To verify propagation properly, you need to check from multiple locations worldwide. A DNS propagation checker queries DNS servers in different global locations and shows you what each one returns. This lets you see:

• Whether all servers have picked up the new record
• Which regions are still showing old values
• Whether there is an inconsistency that could cause issues

You can do a quick check from the command line:

# Check against Google DNS (not your local cache)
dig @8.8.8.8 example.com A +short

# Check against Cloudflare DNS
dig @1.1.1.1 example.com A +short

But this only checks two servers. For a complete picture, use an online DNS propagation checker that queries servers across multiple global locations simultaneously. Tools like dnsfly.net, or whatsmydns let you see exactly where your records have propagated and where they have not.

Pro tip: Before making DNS changes, lower your TTL to 300 seconds (5 minutes) at least 24 hours in advance. This ensures the old high-TTL records expire from caches before you make the switch. After confirming propagation is complete, raise the TTL back to a normal value like 3600 (1 hour) or higher.

Verifying SSL After DNS Change

SSL certificates are tied to DNS. If your DNS has not propagated, your SSL certificate will not work or worse, visitors will see a security warning that makes your site look unprofessional.

Here is the sequence that matters:

1. You update your DNS to point to the new server
2. DNS propagates across global servers
3. Your hosting provider issues or activates the SSL certificate
4. HTTPS starts working

Most modern platforms (Vercel, Netlify, Cloudflare Pages) automatically provision SSL certificates once DNS is pointed correctly. But the certificate will not be issued until DNS propagation is complete. If you check your site too early, you will see an SSL error even though everything is configured correctly.

What to check:

• Is the certificate issued for the correct domain (including www if applicable)?
• Is the certificate not expired?
• Does the certificate cover all subdomains you are using (check Subject Alternative Names)?
• Is the protocol TLS 1.2 or 1.3?

You can verify this from the command line:

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

Or use an online SSL checker like ssllabs.com or dnsfly.net/ssl-checker to get a quick overview of the certificate status, expiry date, issuer, and protocol version without touching the terminal.

Common SSL issue after deployment: You pointed the domain using a CNAME but the SSL certificate only covers the root domain, not the www subdomain (or vice versa). Always verify that your certificate’s Subject Alternative Names (SANs) include all the hostnames you intend to use.

Common Deployment DNS Issues and Fixes

After working with DNS during deployments, certain issues come up repeatedly. Here are the most common ones and how to fix them.

Site works on www but not the root domain (or vice versa)

This usually means you have a record for one but not the other. You need both: typically an A record for the root domain and a CNAME for www pointing to the root. Check both using a propagation tool to confirm they resolve correctly.

Site loads but shows the wrong content

Your DNS might still be pointing to the old server. Check propagation globally. If some locations show the old IP and others show the new one, propagation is still in progress. Wait for it to complete. If all servers show the old IP, your DNS change did not save correctly. Go back to your DNS provider and verify.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

This typically means the SSL certificate has not been provisioned yet because DNS has not fully propagated. Wait for propagation to complete, then check again. If it persists, verify your hosting platform has SSL enabled and supports your domain.

Email stopped working after DNS change

If you changed nameservers or DNS provider, your MX records may not have been carried over. This is one of the most overlooked issues during migration. Before changing DNS, note down all existing records, especially MX, SPF (TXT), and DKIM records. Re-create them at the new provider.

DNS_PROBE_FINISHED_NXDOMAIN

This means the domain does not resolve at all. Either the DNS record does not exist, the domain has expired, or the nameservers are misconfigured. Check your domain registration status and verify that NS records are pointing to the correct DNS provider.

Changes not reflecting after hours

Check the TTL on your previous record. If it was set to 86400 (24 hours), caches worldwide will hold the old value for up to a day even after you update it. This is why lowering TTL before making changes is important. Also try flushing your local DNS cache:

# Windows
ipconfig /flushdns

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

# Linux (systemd)
sudo systemd-resolve --flush-caches

Pre-Deployment DNS Checklist

Before you switch DNS for any deployment, run through this checklist.

24 hours before the change:

• Document all current DNS records (A, AAAA, CNAME, MX, TXT, NS)
• Lower the TTL on records you plan to change to 300 seconds
• Verify the new hosting platform is ready and serving your app correctly on its default URL

During the change:

• Update DNS records at your provider
• Double check the record type (A vs CNAME) matches what your host requires
• Re-create MX, SPF, DKIM, and DMARC records if you changed nameservers
• Do not delete old records until new ones are confirmed working

After the change:

• Check DNS propagation globally using an online propagation checker (whatsmydns.net, or dnsfly.net)
• Verify SSL certificate is active and valid using an SSL checker (ssllabs.com or dnsfly.net/ssl-checker)
• Test the site from a different network or device (not your local machine)
• Check that email is still working (send a test email)
• Monitor for 24-48 hours until propagation is fully complete
• Raise TTL back to normal (3600 or higher) once everything is confirmed

DNS issues during deployment are almost always preventable. The key is preparation: document your records, lower your TTL, make the change, and verify propagation globally before assuming everything is working. A few minutes of verification saves hours of debugging.