How I Fixed Mixed Nameservers and DNS Propagation Hell

It was 10:14 PM on a Tuesday when the first support ticket came in: "The site is down with an SSL error, but only for some of our customers." Within ten minutes, another user sent a screenshot showing a generic Vercel 404 screen.

But on my machine, the site loaded perfectly. I opened my phone, switched off Wi-Fi to hit cellular data, and got a clean page. I hopped back onto my laptop, loaded an incognito window, hit refresh, and suddenly—there it was: NET::ERR_CERT_COMMON_NAME_INVALID. Five seconds later, another refresh, and it loaded again.

I was officially in DNS propagation hell.

When a site behaves like a quantum particle—existing in both working and broken states depending on who is looking at it—the culprit is almost always a split-authority nameserver conflict. Here is exactly how I diagnosed and fixed a broken multi-provider DNS setup that was silently breaking our production environment.

🏗️ The Production Setup

To understand what went wrong, you first need to look at how the infrastructure was mapped:

Frontend: Next.js deployed on Vercel.
Backend: FastAPI Python service running on a DigitalOcean Droplet.
DNS Registrar: NestNepal (a local registrar where the .com.np domain was purchased).
DNS Manager: Cloudflare (for caching, proxying, and SSL termination).

The plan was simple: the domain was registered on NestNepal, but the nameservers were supposed to point entirely to Cloudflare. Cloudflare would then handle SSL, proxy the backend subdomain (api.mydomain.com.np) to the DigitalOcean droplet, and delegate the root domain (mydomain.com.np) to Vercel.

It looked great on paper. In practice, it was a ticking time bomb.

🔬 The Diagnosis: Spotting Mixed Nameservers

The intermittent nature of the failure was the biggest clue. If a backend server is down, it stays down. If a configuration file is corrupt, it fails 100% of the time. But when a site works for 50% of requests, it means the internet is asking two different sources where your website is, and only one of them has the correct answer.

I opened my terminal and queried the domain's authoritative nameservers directly using dig:

$ dig mydomain.com.np NS +short

The output was horizontal proof of the disaster:

ns1.nestnepal.com.
ns2.nestnepal.com.
alec.ns.cloudflare.com.
heather.ns.cloudflare.com.

The registrar had failed to clean up its defaults. When I updated the nameservers in the NestNepal portal, the registrar appended the Cloudflare nameservers instead of replacing the existing ones.

As a result, four authoritative nameservers were registered in the parent zone registry. Because resolver servers query authoritative nameservers using round-robin distribution:

50% of queries hit Cloudflare's nameservers, which correctly pointed visitors to Vercel and DigitalOcean.
50% of queries hit NestNepal's default nameservers, which knew absolutely nothing about Vercel, returning dead A-records or throwing SSL validation errors because the default host didn't have Vercel's certificate.

🛠️ The Fix: Establishing a Single Source of Truth

To resolve the conflict permanently, I had to ensure that Cloudflare held 100% of the DNS authority. I executed the fix in three steps.

Step 1: Purging Default Nameservers at the Registrar

I logged into the NestNepal admin portal, opened the domain management page, and deleted the registrar's default nameservers entirely. I made sure only the custom Cloudflare nameservers remained:

alec.ns.cloudflare.com
heather.ns.cloudflare.com

Step 2: Mapping DNS Records Inside Cloudflare

Next, I logged into Cloudflare and recreated all required records to map the traffic correctly. Since Vercel handles its own global SSL and routing, I had to configure the root domain to point to Vercel's IP, and use a CNAME for the www subdomain.

Crucially, because Vercel manages its own certificates, I set the Cloudflare proxy status to DNS Only (Gray Cloud) for the Vercel records. This bypasses Cloudflare's proxying for the frontend, letting Vercel handle SSL termination directly, which prevents common "Flexible SSL redirect loops".

For the FastAPI backend on DigitalOcean, I set the proxy status to Proxied (Orange Cloud) to take advantage of Cloudflare's DDoS protection.

Here is the exact record table I configured inside Cloudflare:

🔍 Verifying the Resolution

DNS propagation takes time because ISPs cache nameserver responses heavily. To make sure the parent registry had updated, I ran dig with the +trace flag to observe the full resolution pathway from the root servers down to my domain:

$ dig mydomain.com.np NS +trace

The trace confirmed that the root .np servers successfully delegated queries exclusively to Cloudflare's servers:

mydomain.com.np.       86400   IN      NS      alec.ns.cloudflare.com.
mydomain.com.np.       86400   IN      NS      heather.ns.cloudflare.com.
;; Received 98 bytes from 194.0.2.1#53(np) in 48 ms

I also monitored the global propagation using dnschecker.org. Within an hour, nameserver queries from Singapore, London, and New York were returning 100% Cloudflare responses. The intermittent 404s and SSL invalid errors disappeared completely.

💡 Key Takeaway

Never split DNS authority across multiple providers. One provider must own the nameservers—and only that provider. If you want Cloudflare to manage your security, route all your nameservers to Cloudflare and manage A, CNAME, and TXT records solely inside its dashboard.

Keeping a registrar's default nameservers active while attempting to configure third-party routing is a shortcut to production downtime. Clean your registries, verify with dig, and verify from root traces!