Audit history and restore

Audit history

The core stores zones event-based: every change is an event, and the current state is the result of their sequence. The history is therefore not a log maintained after the fact but the data source itself — it cannot possibly be incomplete.

EE makes it accessible:

GET /api/v1/zones/{id}/history

In the UI, the zone view shows the same entries: timestamp, kind of change and the affected Record Sets.

CE stores these events as well — it merely lacks the access to them.

Time-travel restore

POST /api/v1/zones/{id}/restore

Rolls a zone back to an earlier point in time. What matters is the how: the old state is re-applied as new events instead of rewinding or deleting the history.

This has two consequences:

• The history remains complete. The restore itself is visible in it, too.
• A restore is reversible — you can go back to the state before it.

After that, the normal flow takes over: the restored desired state is written to the provider.

Note

The restore operates on the desired state. Whatever was changed directly at the provider since the target point in time subsequently shows up as drift and can be selectively adopted or enforced.