CloudflareProvider._apply_update() - Lack of old/new record "alignment" can lead to failed updates

Context

I encountered this bug while working on #264 and initially thought it was a Cloudflare API bug.

Description

New record contents are extracted here and notice what determines the ordering of adds insertion (the hashes/digests of the new record contents and iteration of the new_contents dict).

Existing record contents are gathered here and notice what determines the ordering of the iteration (response from the Cloudflare API).

The problem arises when you are updating two records with the same name and type, which leads you to this block.

Let’s use an example:

test:
  ttl: 120
  type: A
  values:
    - 1.2.3.4
    - 1.2.3.5

-->

test:
  ttl: 122
  type: A
  values:
    - 1.2.3.4
    - 1.2.3.5

If these lines execute such that add_content’s value does not match record’s value, the PUT update remote call ends up trying to tell Cloudflare to have two records with the same (name, type, value) but differing TTL.

This doesn’t make sense logically and hence Cloudflare blocks the attempt.

If the add_content and record values “align”, then the update makes sense and hence succeeds.

I couldn’t work out why the Cloudflare errors were seemingly stochastic, but I hope I’ve made it obvious why that was the case. The occurrence of “mis-alignment” is determined by: hash/digest of the new record contents, Python interpreter iteration order and Cloudflare record response order.

P.S. I haven’t checked if this issue exists in the other providers.

Fix

Instead of “chancing” the order of iteration of old and new, I think there needs to be some kind of machinery put in place for ensuring that updates with the same (name, type, value) have the new and old contents “align” during the actual remote Cloudflare API call.

[ross]

Extremely swamped atm between work & personal stuff going on so haven’t been able to dig into this. It’s on my todo list and I will take a look once I get down to it.

[ross]

Figured out what the problem is here, but the fix is going to be pretty involved, basically re-writing _apply_Update. Working through that now.