Reverse zones made easy: suggested, filled, in the right view, PTRs kept in step

Missing reverse zones are suggested for the private views' A and AAAA records (/24 for private IPv4, /32 for a public address, /48 for IPv6) and created filled with PTR records (jarl zone suggest-reverse, the Zones page). zone create --fill and zone fill-ptr add the PTRs a reverse zone lacks; a reverse zone created without a view goes to the private view using its addresses. Per zone, auto_ptr keeps the PTR records of A and AAAA records in step on every change (database version 12). Zone commands take a network.

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

docs/reverse.md

@@ -0,0 +1,101 @@
+# Reverse zones
+
+A reverse zone answers "which host has this address?" with PTR records:
+`20.10.0.10.in-addr.arpa. PTR nas.adbraun.lol.`. Your own clients use them
+for names in logs, `traceroute`, the router's client list and `ssh`
+warnings. For your private networks they only exist if this server has
+them, and they are easy to forget, so Jarl can work them out from the
+records you already have.
+
+Who asks matters:
+
+* **Your own clients** ask this server, so a reverse zone in a private
+  view (internal) answers them.
+* **The internet** asks whoever owns the address: your ISP or hosting
+  provider for public addresses. Mail servers check those PTR records, and
+  you set them in the provider's panel, not in Jarl. The Exposure page
+  checks them ([exposure.md](exposure.md#mail)). A reverse zone for a
+  public address in a public view (external) does nothing unless the owner
+  delegated it to you.
+
+So reverse zones belong in private views. A view whose clients reach it
+from the internet gets no suggestions.
+
+## Missing reverse zones
+
+The Zones page lists, under **Missing reverse zones**, the reverse zones a
+private view lacks for the addresses of its A and AAAA records, with
+**Create** (or **Create all**):
+
+```
+$ jarl zone suggest-reverse
+VIEW      NETWORK              ZONE                              PTRS  FOR EXAMPLE
+internal  10.0.10.0/24         10.0.10.in-addr.arpa              14    10.0.10.1 router.adbraun.lol, 10.0.10.5 nas.adbraun.lol, ...
+internal  139.144.144.154/32   154.144.144.139.in-addr.arpa      1     139.144.144.154 ldn.adbraun.lol
+internal  fdab:abab:abab::/48  b.a.b.a.b.a.b.a.b.a.d.f.ip6.arpa  9     fdab:abab:abab:10::5 nas.adbraun.lol, ...
+
+$ jarl zone suggest-reverse --create      # all of them, filled, in one changeset
+```
+
+* A private IPv4 address (10/8, 172.16/12, 192.168/16, 100.64/10) gets its
+  **/24**.
+* A public IPv4 address gets a **/32** zone of its own. The rest of its /24
+  belongs to others, and a /24 zone here would answer NXDOMAIN to your
+  clients for all of their addresses.
+* An IPv6 address gets its **/48**: one zone for every subnet of your
+  prefix (a ULA, or the /48 your ISP delegates). If you have a /56, create
+  that instead (`jarl zone create 2a02:db8:1:ab00::/56`).
+
+Loopback and link-local addresses, wildcards and disabled records are left
+out.
+
+## Creating and filling
+
+```sh
+jarl zone create 10.0.10.0/24 --fill       # the view whose records use 10.0.10.x
+jarl zone fill-ptr 10.0.10.0/24            # later: add what is missing
+```
+
+**The view.** A reverse zone created without `--view` goes to the private
+view whose records use addresses in its network. If none does, it goes to
+the only private view. If several do, Jarl asks you to name the view, or
+to create the zone in each.
+
+**Fill** adds a PTR record for every address in the network that the
+view's A and AAAA records use. An address with several names gets one PTR:
+
+1. the name of a mail or name server (an MX or NS target), else
+2. a host's name rather than the domain's own (`nas.adbraun.lol`, not
+   `adbraun.lol`), else
+3. the shortest name, then the first alphabetically.
+
+Jarl says which name it chose, and which it didn't, so you can change it.
+A reverse zone's page shows how many addresses still lack a PTR, with a
+button to add them. `jarl zone show` shows it as `Missing PTRs`.
+
+## Keeping PTR records in step
+
+The **Update PTR** box on an A or AAAA record (`--ptr`) moves the PTR record
+along with that one change. To have that on every change, turn it on for
+the forward zone:
+
+```sh
+jarl zone update adbraun.lol --view internal --auto-ptr          # off: --auto-ptr=false
+```
+
+(Zone settings → **Reverse DNS** in the web UI.) Then adding, changing,
+disabling, enabling or deleting an A or AAAA record in the zone does the
+same to its PTR record, in the reverse zones of the zone's view and of the
+views it is linked with ([views.md](views.md#linked-zones)). A whole set
+replaced at once (`jarl record set`, a batch) works too.
+
+* **One name per address.** When an address's PTR record names another
+  host, it stays: a second A record for the same address doesn't add a
+  second PTR record.
+* **No reverse zone, no PTR.** An address without a reverse zone in the
+  view, such as a public address in the external view, is skipped without
+  a warning. The suggestions above show what is missing.
+* **Wildcards** (`*.dev`) never get a PTR record.
+
+The PTR changes are part of the same changeset, so you review them, and
+they are applied or undone together with the record.