Why Subdomains Get Blocked by Cloudflare After Root DNS Changes

The Mystery of the Ghost Security Guard

Imagine you run a successful business. Your main headquarters is at one address, and you have a specialized, modern annex just down the street for your VIP clients. One day, you decide to close down the physical headquarters building entirely. You move its operations elsewhere, but you keep the annex running exactly as it was.

To your surprise, clients trying to enter the annex are suddenly stopped at the gate, forced to prove they are not robots. What happened? You closed the headquarters, not the annex! This is exactly the situation many developers face when they delete a root domain A record but their subdomain keeps triggering Cloudflare reCAPTCHA challenges.

Understanding DNS Records: They Are Independent of Each Other

Before we dive into Cloudflare's security features, let's clarify a common misconception. A DNS A record and a CNAME record are completely separate entries in your DNS configuration. Think of them like two different pages in an address book. Deleting one page does not affect the other at all.

• A Record: Points a domain name (like ginbok.com) directly to an IP address. It is the most basic type of DNS record.
• CNAME Record: Points a subdomain (like note.ginbok.com) to another domain name (like cname.vercel-dns.com). It is used for services hosted on platforms like Vercel, Netlify, or GitHub Pages.

When you deleted the A record for ginbok.com, you only removed the address for the main building. The annex at note.ginbok.com, managed by its own CNAME record pointing to Vercel, kept running independently without any interruption.

The Orange Cloud vs. The Grey Cloud: Proxied vs. DNS Only

This is where Cloudflare enters the picture. When you add a DNS record in Cloudflare, you will notice a cloud icon next to it. This cloud icon is one of the most important settings you can configure.

• Orange Cloud (Proxied): All traffic to your subdomain first passes through Cloudflare's global network of servers before reaching your actual hosting (Vercel, in this case). Cloudflare acts as the middleman, or proxy. This enables all of Cloudflare's features: caching, DDoS protection, WAF rules, and Bot Fight Mode.
• Grey Cloud (DNS Only): Traffic goes directly from the user's browser to your hosting provider. Cloudflare simply acts as a DNS lookup service. None of Cloudflare's security filters are applied to the traffic.

Since note.ginbok.com is set to Proxied (Orange Cloud), every request to your subdomain is being inspected by Cloudflare's security layer. This is why the reCAPTCHA is appearing.

What Are Bot Fight Mode and WAF Rules?

Cloudflare offers powerful security features to protect websites from malicious bots and attacks. Two of the most common culprits behind unexpected reCAPTCHA challenges are:

• Bot Fight Mode: This feature automatically identifies and challenges traffic that looks like it comes from automated bots. The problem is that it can sometimes mistake legitimate developer activity (like rapidly reloading a page during testing or making frequent API calls from a single IP address) for bot behavior. You can find this setting under Security > Bots in your Cloudflare dashboard.
• WAF (Web Application Firewall) Rules: These are customizable rules that block or challenge specific types of requests. If a WAF rule is set too aggressively, it may challenge normal browsing sessions. Check your WAF rules under Security > WAF.
• Security Level: Cloudflare has a general security level setting (Low, Medium, High, Under Attack). If it is set to High, it will challenge more visitors. You can adjust this under Security > Settings.

How to Debug Using the Ray ID

When you see a reCAPTCHA page from Cloudflare, you will notice a unique code at the bottom called a Ray ID. This is your best debugging tool. Here is how to use it:

1. Go to your Cloudflare dashboard and navigate to Security > Events.
2. You will see a log of all blocked or challenged requests.
3. Filter by the subdomain note.ginbok.com or find the event matching the time you were challenged.
4. Click on the event. Cloudflare will tell you exactly which service triggered the challenge: Bot Fight Mode, a WAF Rule, or IP Reputation.

This removes all the guesswork. You will know precisely which feature to disable or adjust.

The Fastest Solution: Switch to DNS Only

If you do not need Cloudflare's advanced features (like Zaraz analytics, custom WAF rules, or Cloudflare Workers) for your note.ginbok.com subdomain, the fastest fix is to bypass Cloudflare's proxy entirely.

Here is why this is perfectly safe: Vercel, the hosting platform your subdomain points to, already provides enterprise-grade SSL certificates and its own robust security infrastructure. You are not giving up security by disabling the Cloudflare proxy for this subdomain.

Steps to fix it:

1. Log in to your Cloudflare dashboard.
2. Go to DNS > Records.
3. Find the CNAME record for note.ginbok.com.
4. Click the orange cloud icon to toggle it to a grey cloud (DNS Only).
5. Save the change.

Traffic will now flow directly from the user's browser to Vercel, completely bypassing Cloudflare's security filters. The reCAPTCHA challenge will disappear immediately.

Quick Summary

To recap: deleting the A record for your root domain has absolutely no effect on your subdomain's security settings. The reCAPTCHA is caused by Cloudflare's Bot Fight Mode or WAF rules being applied to the Proxied CNAME record for note.ginbok.com. You can either disable the specific security feature causing the challenge (found via the Ray ID in Security Events), or simply switch the subdomain to DNS Only mode and let Vercel handle security directly.