search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.69k stars 907 forks source link

Conflict detection in the API #6247

Open hlindqvist opened 6 years ago

hlindqvist commented 6 years ago

Short description

When updating RRSets in an existing zone via the API, there is no mechanism to detect conflicting changes. This in turn makes it hard to update existing record sets without risk of overwriting other recent changes (requires the use of some external locking mechanism to really be safe).

If there are multiple actors that want to update the same RRSet, these could inadvertently end up reverting each other's changes. (Imagine two or more things in parallel that do: GET zone data, modify relevant RRSet, PATCH zone data with modified RRSet.)

Usecase

The lack of conflict detection has pretty broad implications, but for most cases it's unlikely that conflicts occur in practice. Even in these general terms, it would of course be good to have a mechanism to allow for moving away from it being (usually) unlikely to it being impossible that API clients inadvertently revert each other's changes.

An example where this safeguard would be particularly relevant is if you have two or more automated tasks that maintain records in the same RRSet. For instance TXT at the zone apex is an example of an RRSet that often has "mixed use".

Another example would be an editing UI, used in parallel by multiple users.

It may also be relevant to ensure consistency for cross-RRSet dependencies (ie referenced names).

Description

Where you currently just specify the new RRSet in your PATCH request and it overwrites the existing RRSet no questions asked, it would be preferable that the request (optionally) specifies which "version" you were modifying and that, in case of conflict, nothing happens and you just get a HTTP 409 response (or whatever status code is deemed applicable).

This way, in case conflicting changes have happened while the request was prepared, no inconsistency is introduced in the zone data and the API client which lost this race would know this and could retry constructing its request if that is desirable.

For reference: RFC2136 has its concept of "prerequisites" that can be used for this purpose when modifying zone data using that mechanism.

Habbie commented 4 years ago

I totally duplicated this in #8592. Closing that one.