Using Common DDNS Subdomains May Cause China Telecom Broadband Service Degradation
Categories:
I have been troubleshooting IPv6 disconnections and hole-punching failures for over three months. I’ve finally identified the root cause; here’s the story.
My First Post Asking for Help—IPv6 Disconnections
IPv6 had been working perfectly. Without touching any settings, and even though every device had its own IPv6, it suddenly lost IPv6 connectivity entirely.
curl 6.ipw.cn returned nothing, and both ping6 and traceroute6 2400:3200::1 failed.
My ONT was bridged to the router, and I could still obtain the router’s own IPv6—one that could still reach the IPv6 Internet.
I received a /56 prefix, and all downstream devices received addresses within 240e:36f:15c3:3200::/56, yet none could reach any IPv6 site.
I suspected the ISP had no route for 240e:36f:15c3:3200::, but I couldn’t prove it.
Someone suggested excessive PCDN upload traffic was the culprit, but upload volume was minimal and PCDN wasn’t enabled.
Another possibility was that using Cloudflare and Aliyun ESA reverse proxies had caused it.
My Second Post—Finding a Direct Cause
I confirmed that at least some regions of China Telecom will downswitch service when they see many inbound IPv6 HTTP/HTTPS connections, manifesting as:
- Fake IPv6: You still get a
/56, every device keeps its IPv6, but traceroute lacks a route, so IPv6 is de-facto unusable. - Fake hole- punch: Tailscale reports its connection is direct, yet latency is extreme and speed is terrible.
Every time I disabled Cloudflare/Aliyun ESA proxying and rebooted the router a few times, both real IPv6 connectivity and true direct Tailscale worked again.
Still Disconnects After Disabling Reverse Proxy
Even with proxy/CDN disabled—complete direct origin access—I still had occasional outages lasting hours.
Perhaps my domain had leaked, or bots were scanning popular subdomains with a steady HTTP attack.
When I disabled DNS resolution for the DDNS hostname outright, IPv6 came back after a while, and Tailscale hole-punching was again direct and stable.
Since then those disconnections never returned.
My Final Recommendation
Avoid using commonplace DDNS subdomains, such as:
- home.example.com
- nas.example.com
- router.example.com
- ddns.example.com
- cloud.example.com
- dev.example.com
- test.example.com
- webdav.example.com
I had used several of these; it seems they are continuously scanned by bots. The resulting flood of requests triggered China Telecom’s degradation policy, making my IPv6 unusable and blocking hole-punching.
As you already know, hiding your IP matters in network security; the same goes for protecting the domain you use for DDNS—that domain exposes your IP as well.
If you still need public services, you have two practical choices:
- Proxy/Front-end relay—traffic hits a VPS first, then your home server. Latency and bandwidth suffer because traffic takes a detour.
- DDNS direct—everything connects straight to you. Performance is much better; this is what I recommend. For personal use the number of connections rarely hits the limit, but once the domain becomes public the bots will ramp it up quickly.
Proxy Relay (Reverse Proxy)
Cloudflare Tunnel
Use Cloudflare’s Tunnel so you won’t see the dozens or hundreds of IPs typical of ordinary reverse proxies.
Tailscale or ZeroTier
Build your own VPN, put a VPS in front, and reach your LAN services through the VPN. This avoids excessive simultaneous connections.
DDNS Direct Scheme
Public DNS
Generate a random string—like a GUID—and use it as your DDNS hostname. It’s impossible to remember, but for personal use that’s acceptable. Judge for yourself.
Private DNS
Run your own DNS service, e.g.:
Configure it to serve your DDNS records; only people who can query your private DNS will resolve the custom IP.
In this model you can use common DDNS names, but take care never to expose the address of your private DNS server.
Afterthought
Rumor has it that naming a subdomain speedtest might provide a mysterious boost.