Disable records instead of deleting them

A disabled record stays in Jarl with its ID, TTL and comment but is
left out of the zone; the zone file lists it as a comment. Web UI
toggle, jarl record disable|enable, record.disable|enable operations
and API endpoints. Database schema 5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/api.md

@@ -110,7 +110,8 @@ on the resources below, except users and tokens) works the same way:
 
 Reads accept `?changeset=ID` too. They then show the configuration as it
 will be after the changeset, with `"pending": "add" | "change" | "delete"`
-on affected zones and records.
+on affected zones and records (`"disable"` or `"enable"` for a record
+that is only being disabled or enabled).
 
 The response of an applied change:
 
@@ -333,14 +334,18 @@ registrar_error`.
 
 | Method | Path | Body / query |
 |--------|------|--------------|
-| GET | `/zones/{zone}/records` | `?name=`, `?type=`, `?q=` |
+| GET | `/zones/{zone}/records` | `?name=`, `?type=`, `?q=`, `?disabled=1` (only disabled records) or `0` (only enabled ones) |
 | POST | `/zones/{zone}/records` | a RecordInput, or an array of them (one changeset) |
 | DELETE | `/zones/{zone}/records` | `?name=&type=[&data=][&missing_ok=1][&ptr=1]`: delete by match |
+| POST | `/zones/{zone}/records/disable` | same query as delete by match: disable the matching records |
+| POST | `/zones/{zone}/records/enable` | same query: enable them again |
 | PUT | `/zones/{zone}/rrsets/{name}/{type}` | `{"data": ["192.0.2.1", "192.0.2.2"], "ttl": 60, "comment": "..."}`: make the RRset exactly this |
 | DELETE | `/zones/{zone}/rrsets/{name}/{type}` | delete the whole RRset |
 | GET | `/records/{id}` | |
 | PATCH | `/records/{id}` | RecordInput fields to change (`If-Match` supported) |
 | DELETE | `/records/{id}` | `?ptr=1` also deletes the matching PTR |
+| POST | `/records/{id}/disable` | `?ptr=1` also disables the matching PTR |
+| POST | `/records/{id}/enable` | `?ptr=1` also enables the matching PTR |
 
 RecordInput:
 
@@ -351,12 +356,26 @@ RecordInput:
   "data": "192.0.2.10",        // zone file syntax; TXT/SPF take plain text
   "ttl": 300,                  // null or absent: the zone's default TTL
   "comment": "web server",
-  "ptr": true                  // A/AAAA: also create/move/delete the PTR in the reverse zone
+  "disabled": false,           // true: keep the record in Jarl but out of the zone
+  "ptr": true                  // A/AAAA: also create/move/delete (or disable/enable) the PTR in the reverse zone
 }
 ```
 
 Responses add `zone`, `view`, `relative_name`, `effective_ttl`, and `text`
-(the decoded value of TXT records).
+(the decoded value of TXT records). Zones have `disabled_count` when
+some of their records are disabled.
+
+**Disabled records** stay in Jarl, with their ID, TTL and comment, but are
+left out of the zone: the zone file lists them as comments (`; disabled:
+www IN A 192.0.2.10`). Disabling and enabling are ordinary changes (staged,
+reviewed, reverted like any other). Validation checks the zone as it is
+served, so disabling the zone's last NS record is refused, and enabling a
+record is checked as if it were added: a CNAME added at its name in the
+meantime stops it (and gives a `disabled_conflict` warning until then).
+`PUT /rrsets` makes the RRset exactly the given data: a disabled record
+with one of the values is enabled, other disabled records are left alone.
+Disabling a record that is already disabled is a 409; with `missing_ok=1`
+(by match) it's "nothing to do".
 
 ### Views
 
@@ -436,6 +455,7 @@ An **Operation** is `{"op": "...", "id": 0, "base_version": 0, "data": {...}}`:
 | `record.create` | | RecordInput + `"zone": "adbraun.lol"` (or `zone_id`) and `"view"` |
 | `record.update` | record | RecordInput |
 | `record.delete` | record, or 0 with `zone`, `name`, `type`, optional `data`, `missing_ok`, `ptr` | |
+| `record.disable` / `record.enable` | record, or 0 with the same match fields as `record.delete` | stored as `record.update` operations |
 | `rrset.replace` | | `{"zone", "view", "name", "type", "ttl", "data": [...]}` (empty data deletes the RRset) |
 | `view.create` / `view.update` / `view.delete` / `view.reorder` | view (update/delete) | ViewInput / `{"ids": [...]}` |
 | `acl.create` / `acl.update` / `acl.delete` | ACL | ACL fields |

docs/cli.md

@@ -245,7 +245,7 @@ Jarl.)
 ## Records
 
 ```sh
-jarl record list adbraun.lol [--name www] [-t A] [--search nas]
+jarl record list adbraun.lol [--name www] [-t A] [--search nas] [--disabled]
 jarl record add adbraun.lol nas A 192.168.1.20 --ptr --comment "synology"
 jarl record add adbraun.lol @ MX 10 mail
 jarl record add adbraun.lol @ TXT "v=spf1 mx -all"      # plain text, quoting is automatic
@@ -257,6 +257,9 @@ jarl record update 1234 --ttl default
 jarl record delete adbraun.lol www A                      # every A record of www
 jarl record delete adbraun.lol www A 192.168.1.10         # just this one
 jarl record delete --id 1234 [--ptr]
+jarl record disable adbraun.lol www A 192.168.1.10 --ptr  # out of the zone, kept in Jarl
+jarl record enable adbraun.lol www A 192.168.1.10 --ptr   # back again
+jarl record disable --id 1234                             # by ID; same for enable
 
 # reverse zones: name records by address; the host name needs no final dot
 jarl record add 0.10.10.in-addr.arpa 10.10.0.20 PTR nas.adbraun.lol
@@ -273,6 +276,16 @@ by Jarl). Every record type BIND supports can be used. Jarl knows the
 syntax of the common ones and checks them strictly, and the rest are
 validated by parsing.
 
+**Disabling** a record takes it out of the zone without deleting it: it
+keeps its ID, TTL and comment, the zone file lists it as a comment
+(`; disabled: www IN A ...`), and `enable` puts it back exactly as it
+was. `record list` marks disabled records `[disabled]`, and `zone show`
+counts them. The zone is validated as it is served: you can't disable its
+last NS record, and enabling a record is checked like adding it (a CNAME
+added at the same name in the meantime stops it). `record set` enables a
+disabled record whose value it is given, and leaves other disabled
+records alone.
+
 ## Batches: `jarl apply -f`
 
 Several changes that must succeed or fail together:
@@ -287,6 +300,7 @@ changes:
   - set:    {zone: adbraun.lol, name: api, type: A, data: [192.168.1.41, 192.168.1.42], ttl: 60}
   - update: {id: 1235, comment: "old web server, remove in November"}
   - delete: {id: 1240}
+  - disable: {zone: adbraun.lol, name: old, type: A}   # or {id: ...}; enable: likewise
   - op: acl.update                     # any API operation (see api.md)
     id: 3
     data: {elements: [192.168.1.0/24, 10.10.0.0/16]}
@@ -430,4 +444,5 @@ See [acme.md](acme.md) for certbot, acme.sh and a dedicated ACME zone.
 * `-q` with `create` commands prints just the ID or token.
 * Check `$?` against the exit code table.
 * `jarl record delete ... --missing-ok` succeeds when nothing matches, which
-  keeps cleanup scripts idempotent. `jarl record set` is idempotent by nature.
+  keeps cleanup scripts idempotent. So does `record disable|enable
+  --missing-ok`, also when the records are already disabled (enabled). `jarl record set` is idempotent by nature.