Add the ability to Update an IP Access rule

[WolfRamAlpha12]

Unsure if this falls within the scope of this project, but I have a feature request:

• Whenever the IP updates, in addition to updating the DNS record, add or update an IP access rule (Security>WAF>Tools) to allow the new IP.

Here are the relevant docs: https://developers.cloudflare.com/api/operations/ip-access-rules-for-a-zone-list-ip-access-rules. It seems CF does not allow the value to be edited (only mode and notes), so upon an IP change the old one would have to be deleted and a new rule with the new IP would be created. For deletion, the API supports filtering the GET results using several optional parameters, including the notes.

Let me know if I can help out in implementing this is any way.

[favonia]

Thanks for the suggestion. I have to admit I'm pretty ignorant about this part of Cloudflare API, and it does seem to be quite tricky. My immediate question is, is there a reliable way to indicate which rule(s) to delete without the invariant we are assuming between the notes on the Cloudflare server and the updater configuration? What could be helpful is that, if you have a working automatic system set up, I would like to learn how it's working now.

PS: I also have to admit that I couldn't devote enough time in this project before summer 2024 to implement interesting new features; even #632 is taking me too long 😟

[WolfRamAlpha12]

My immediate question is, is there a reliable way to indicate which rule(s) to delete without the invariant we are assuming between the notes on the Cloudflare server and the updater configuration?

The notes parameter can be set to an arbitrary string (say This rule was created by cloudflare-ddns on $timestamp) when creating the rule. The work flow may look like:

1. GET request to CF with the filters object (Unsure how it is actually implemented; based on their example, a filter with the notes string set to This rule was created by cloudflare-ddns on should return any rules with the above example string; alternatively store and append a UUID to the notes string and filter by that, the docs show a similar filter as an example). A successful request will return matching rules along with their unique identifier.
2. DELETE request to CF, passing the unique identifier returned above (Only one rule should be returned ideally since we delete the old one every time it updates, but maybe store results returned matching id: "*" and send a DELETE request for each)
3. POST request to CF, creating a new rule, passing the new IP, setting it to allow, and of course, the notes for future filtering.

I don't have an automation setup yet, I found the need for it just before I opened this issue. I'll work on it and post the code here whenever I make it.

[favonia]

@WolfRamAlpha12 I still feel the idea to assign meaning to supposedly totally unstructured notes is not very reliable. But let's put that aside for the moment. Could you possibly explain why PATCH would not work? It seems I could update the IP of a target? Found the statement.

[favonia]

@WolfRamAlpha12 Never mind. I saw the strange documentation that described what you said.

[WolfRamAlpha12]

meaning to supposedly totally unstructured notes is not very reliable.

Appending and filtering a UUID would ensure no false positives. Storing the previously set IP and filtering by that is possible as well, so a query with configuration.target =ip configuration.value =$previousIP mode=whitelist match =all would return rules with an IP of $previousip set to allow

[favonia]

@WolfRamAlpha12 I prefer not to relying on stateful checks because they are fragile. Consider these cases:

1. Some people use external cron to manage the scheduling so the program immediately exits after the IPs are updated.
2. You might also want to restart or even recreate the updater container during upgrades and reboots.
3. A Cloudflare API call can fail for many reasons, including timeout and temporary network outage. When that happens, you cannot reliably know whether the rule has been successfully updated. (That is, you might see that the API call fails, but the change might have been made on the Cloudflare server.)
4. While this shouldn't happen, maybe the rules could be updated or changed by other programs or you manually.

The current stateless design is robust partly because it will eventually fix any inconsistency itself even if all of the above happen. That is, its eventual correctness does not depend on the correctness of the local state. This is the level of robustness I would like to maintain, and it's still a bit difficult for me to see how to achieve that using the current API for the IP filtering rules, but maybe you could help me see it.

[favonia]

@WolfRamAlpha12 Just to clarify, I'm still happy to find a good approach with you and I thank you for the GitHub issue ❤️

[WolfRamAlpha12]

@favonia Thank you, appreciate your willingness to work with me here. I'll keep the above scenarios in mind while trying to make my automation and see if I can come up with something that can meet the current level of robustness.

[jdvuyk]

Hi guys.

I believe this feature is also what I am looking for. Whilst this tool seems amazing at doing the DDNS bit, its hard to use the outcome in a meaningful way within the cloudflare eco-system. I think the answer is 'lists'. You can create a WAF rule based on the contents of a cloudflare list. So if this tool updates an arbitrary lists content, as well as the actual A record, you now have a very powerful tool to both update the record AND make it useable within cloudflares own WAF rules to do whatever you want.

Manage Account --> Configurations --> Lists
https://developers.cloudflare.com/waf/tools/lists/custom-lists/

If it were me, I would have the tool create and manage its own list (like "cloudflare-ddns") and whenever the IP address gets change/updated, delete all items in the list and create one single item that represents the current IP. This is a 'reserved' list that can be used in WAF rules if the user wants to, or simply ignored if users don't need that.

[favonia]

@jdvuyk Thank you for providing the technical bits! I guess we can blame the users if they dare touch a list named ip-addresses-reported-by-cloudflare-ddns...? Now I can better see how these can be made to work!

Question: should we have one list for IPv4 and another for IPv6?

Also tagging @WolfRamAlpha12

PS: I'm still quite burdened by my current daytime job... until 2024 summer at least. I wish to conclude #632 first. But I can do these "easy" discussions. 😁