A few months ago, I started paying attention to Tencent’s new EdgeOne service. It stood out because it does not require ICP filing or real-name verification, and it also includes a free tier, which makes it especially attractive for personal websites. When it first launched, redemption codes were hard to get, so I did not spend much time on it. Later, Tencent ran a campaign where reposting on X (formerly Twitter) earned two codes. I managed to claim one and used it on my site, "Jingyuanxuan."

That site runs on a VPS from CloudCone, and its access speed had never been particularly satisfying. After putting it behind EdgeOne, performance improved noticeably. That experience convinced me to place my blog on the service as well.

The first obstacle: CNAME flattening on the apex domain

When I pointed my blog’s main domain, iliu.org, to the hostname provided by EdgeOne using a CNAME record, EdgeOne would not recognize the DNS setup as valid. What made this confusing was that the same process had worked smoothly for my other site.

After checking the configuration piece by piece, I found the real cause: Cloudflare’s CNAME Flattening.

My blog used the root domain rather than a subdomain, and Cloudflare’s free plan does not allow custom NS records. Because of how its CNAME flattening works, EdgeOne could not properly detect the expected DNS result. At that point, the simplest way forward was to move the domain away from Cloudflare.

Domain transfer solved one problem, then exposed another

I chose Name.com as the new registrar because I had used it before. The transfer cost a bit more than Cloudflare, but the difference was acceptable. Looking back, I probably should have compared more options first—Spaceship may have been a better choice.

Once the domain was transferred to Name.com, EdgeOne finally recognized the CNAME correctly. But another issue appeared right away: the SSL certificate request kept failing.

I dug into the failure and noticed that some DNS servers outside China could not resolve my domain at all. At first, I assumed it was just DNS propagation delay and waited. But even after a week, certain DNS resolvers in the United States and Europe still could not resolve the domain.

Tracing the issue with dig

To get to the bottom of it, I asked Gemini for help. It suggested checking the domain with the dig command. I ran:

<table> <thead> <tr> <th>1</th> <th>dig iliu.org A @8.8.8.8</th> </tr> </thead> <tbody> <tr> <td></td> <td></td> </tr> </tbody> </table>

The response showed status: SERVFAIL, and the EDE section included: 10 (RRSIGs Missing).

That result pointed directly to a DNSSEC signature problem on iliu.org.

The real cause: an old DS record left behind

The issue turned out to be a conflict involving DNSSEC.

I had previously enabled DNSSEC on Cloudflare. For a .org domain, that leaves a DS (Delegation Signer) record at the registry level. In effect, that DS record tells resolvers: this domain uses DNSSEC, so its signatures must be validated through the authoritative name servers.

After the transfer, the authoritative DNS was now handled by Name.com. The problem is that Name.com does not support DNSSEC. That created a mismatch:

• the registry still indicated that DNSSEC validation was required;
• but Name.com could not provide the necessary DNSSEC signatures.

As a result, strict resolvers—particularly some overseas DNS servers—failed validation and returned resolution errors. Meanwhile, some resolvers in mainland China and other parts of Asia were apparently more lenient in practice, so the domain could still resolve there.

That difference in resolver behavior is what made the problem so confusing. Locally, things looked mostly normal, while EdgeOne’s certificate validation kept failing in the background.

The fix

Once I identified the cause, the solution was straightforward. I logged in to Name.com, found the DNSSEC settings, and removed the lingering DS record.

A few minutes later, EdgeOne successfully issued the SSL certificate, and the problem that had been dragging on for days was finally gone.

If you run into a similar situation—EdgeOne sees your CNAME inconsistently, or SSL issuance fails even though the DNS records look correct—it is worth checking two things early:

1. whether CNAME flattening is interfering with apex-domain detection;
2. whether an old DNSSEC DS record is still published after moving the domain to a provider that does not support DNSSEC.

In my case, those two issues appeared one after another, and the second one was much harder to spot than the first.