In November 2021 CloudFlare changed its policy and disabled some partner API resources.

At first glance, this seems like a rather routine action, fully in line with CloudFlare’s strategy, and moreover, quite meaningful from the point of view of cyber security. Here’s how the team at CloudFlare explained the change:

Thanks for contacting Cloudflare support. I am sorry to hear you are having some issues here.

This capability has been deprecated due to a potential security risk. Going forward, zones can be added only in full setup using the API.

Since this was a security risk the step was taken so sudden. Really appreciate your understanding in this matter. We apologize for any inconvenience caused because of this.

The domains that are already active should not be changed or have any effect, however, the new zones going forward would need to be on a full setup.

Unfortunately, a fairly large number of shared hosting providers were previously using this particular API feature to register domains with CloudFlare without the need to transfer the entire domain zone. 

Here’s what one respected hosting CEO from southern Europe had to say: “I have always argued that their long-term goal has always been to reach end users, have their data, and sell them services. They’ve disabled an important overnight feature for Partners and [are] now pushing partners to have an expensive monthly contract”. An extensive discussion on this topic can be found here.

What was a reasonable move for CloudFlare with their end-customer-oriented policy, was an unpleasant surprise for some of their hosting partners. Naturally, the search for a way out of the situation ensued and in the absence of a universal solution, a number of interesting strategies have emerged. Normally this would not be a talking point for us, however one of these strategies is gaining interest as it is not only convenient to manage, but is also stable and reliable in the long term. Hosting providers are starting to consider whether they could build their own “substitute” solution.

Protection against botnets requires two basic components: a malicious traffic detection component to recognize who you need to block, and mitigation tool to implement such blocking. Every hosting provider with a network infrastructure has this second component at their disposal, typically in the form of some hardware tools. Most providers also have expert network engineers who are great at this.

This is what hosting providers need to know: the bot detection component is much more efficient if implemented at the application layer, while the blocking component needs to be implemented at the network infrastructure level because it’s hardly efficient at any higher level.

The detection component can be built based on technology similar to what BotGuard is developing. Of course, any other similar solution should do the job, the only requirement being that the technology is based on high quality bot recognition. Such a component could, for example, report detected bot IP addresses back to the network router for subsequent blocking. Implementation methods may vary, but in general, this is not rocket science.

If you’re interested in starting a discussion about this problem, you are more than welcome to drop me a message at d.prochko (at) botguard.net.