Reverse zone suggestions: yours and public, dismiss, per-view switch; child zones take their records

Suggestions split into networks that are yours (private IPv4 /24, ULA /48, an IPv6 /48 this server has an address in), which Create all creates, and public addresses (/32 or /128) to create only if they are yours or dismiss. A view can turn suggestions off, which also keeps it out of choosing a reverse zone's view (database version 13). A zone created inside another in the same view takes the parent's records under it; a delegation and its glue stay, a linked parent keeps them with a warning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
adamandClaude Opus 5.5 committed 2026-10-12 22:01:18 +01:00
1 parent aa4b004a14
commit b24c730b97
21 files changed
+543 -107

No files matched your search

+2 -1
View File
@@ -361,7 +361,8 @@ and `linked_with` (the other views).
| POST | `/zones/{zone}/link` | `{"with": ["external"]}` (default: every view with that zone). Names and types that are the same everywhere become shared, the rest stay local |
| POST | `/zones/{zone}/unlink` | Takes the zone out of its link; its records stay, all local |
| POST | `/zones/{zone}/fill-ptr` | Adds the PTR records a reverse zone lacks for its view's A and AAAA records ([reverse.md](reverse.md)) |
| GET | `/reverse-zones/suggestions` | The reverse zones the private views lack: `view_id`, `view`, `prefix`, `zone`, `why`, `fill` (PTR records it would get), `samples` |
| GET | `/reverse-zones/suggestions` | The reverse zones the private views lack: `view_id`, `view`, `prefix`, `zone`, `group` (`yours`, or `public`: only if the address is yours), `why`, `fill` (PTR records it would get), `samples` |
| POST | `/reverse-zones/dismiss` | `{"view": "internal", "prefix": "185.199.108.153/32"}`: don't suggest it again (`/undismiss` brings it back). A view's `reverse_suggestions: false` (PATCH `/views/{id}`) stops its suggestions |
| GET | `/zones/{zone}/compare` | The zone across the views that have it (`?views=a,b`; `?all=1` also the same rows): `views`, `linked`, `same` (count) and `rows` (name, type, `same`, per view `records`, `ids`, `linked`). The zone may be named without a view |
`POST /zones` takes `"link_with": "VIEW"` to create a zone linked with
+3 -1
View File
@@ -179,7 +179,9 @@ jarl zone create 10.0.8.0/22 # four zones, 8-11.0.10.i
jarl zone create 10.0.10.100/32 # a zone for just that address
jarl zone create 10.0.10.0/24 --fill # in the view whose records use it, with their PTRs
jarl zone fill-ptr 10.0.10.0/24 # add the PTRs it lacks (zone commands take a network too)
jarl zone suggest-reverse [--create] # reverse zones your private views lack
jarl zone suggest-reverse [--create] # reverse zones your private views lack (--create: yours)
jarl zone suggest-reverse --dismiss 185.199.108.153/32 --view internal # not yours: don't suggest it again
jarl view update vps --reverse-suggestions=false # no suggestions for this view
jarl zone update adbraun.lol --auto-ptr # keep PTRs in step with the A/AAAA records (docs/reverse.md)
jarl zone create adbraun.lol --view external --clone-from adbraun.lol --clone-view internal
jarl zone create partner.example --type secondary --primary "192.0.2.53 key xfer"
+2 -1
View File
@@ -260,7 +260,8 @@ boundary. So:
Jarl suggests the reverse zones your private views lack, creates them in
the right view filled with PTR records, and can keep PTR records in step
with a zone's A and AAAA records: [reverse.md](reverse.md).
with a zone's A and AAAA records: [reverse.md](reverse.md). A zone created
inside another (a /24 inside a /8) takes the parent's records under it.
### Dynamic updates and TSIG keys
+45 -19
View File
@@ -19,32 +19,49 @@ Who asks matters:
delegated it to you.
So reverse zones belong in private views. A view whose clients reach it
from the internet gets no suggestions.
from the internet gets no suggestions, and neither does a view you turn
them off for: a view only a few servers use, such as one for your VPS,
matches only their addresses and so counts as private, but its clients
don't need reverse zones (`jarl view update vps
--reverse-suggestions=false`, or the view's settings). Exposure doesn't
change.
## 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**):
private view lacks for the addresses of its A and AAAA records, in two
groups:
```
$ 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, ...
GROUP VIEW NETWORK ZONE PTRS FOR EXAMPLE
yours internal 10.0.10.0/24 10.0.10.in-addr.arpa 14 10.0.10.1 router.adbraun.lol, ...
yours internal 2a02:8013:7f3d::/48 d.3.f.7.3.1.0.8.2.0.a.2.ip6.arpa 9 2a02:8013:7f3d:10::5 nas.adbraun.lol, ...
public internal 139.144.144.154/32 154.144.144.139.in-addr.arpa 1 139.144.144.154 ldn.adbraun.lol
public internal 185.199.108.153/32 153.108.199.185.in-addr.arpa 1 185.199.108.153 blog.adbraun.lol
$ jarl zone suggest-reverse --create # all of them, filled, in one changeset
$ jarl zone suggest-reverse --create # yours, filled, in one changeset
$ jarl zone create 139.144.144.154/32 --view internal --fill # a public one that is yours
$ jarl zone suggest-reverse --dismiss 185.199.108.153/32 --view internal # GitHub's, not yours
```
* 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`).
**Yours**, created by **Create all** (`--create`):
* the **/24** of a private IPv4 address (10/8, 172.16/12, 192.168/16,
100.64/10);
* the **/48** of a ULA (fd00::/8), or of a public IPv6 prefix this server
has an address in (the /48 your ISP delegates): one zone for all its
subnets. If you have a /56, create that instead (`jarl zone create
2a02:db8:1:ab00::/56`).
**Public addresses, only if they're yours**: any other public address,
each as a /32 (or /128) of its own. Jarl can't tell your VPS from a web
host's server (a `blog` record pointing at GitHub Pages), and a zone for
someone else's address would show your clients your name for it instead
of theirs. The rest of the /24 belongs to others: a /24 zone here would
answer NXDOMAIN to your clients for all of their addresses. Create the
ones that are yours one by one, and **Dismiss** the others: Jarl
remembers, per view (`--undismiss` brings one back).
Loopback and link-local addresses, wildcards and disabled records are left
out.
@@ -57,9 +74,18 @@ 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.
view whose records use addresses in its network (views with suggestions
off don't count). 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.
**Inside another zone.** A zone created inside an existing one in the same
view, a /24 inside a /8 or `lab.adbraun.lol` inside `adbraun.lol`, takes
the parent's records under it, in the same changeset: named answers those
names from the new zone, so left in the parent they would never be served
again. PTR records you added by hand come along; `--fill` then adds only
what is still missing. A delegation (NS records at the new zone's name,
with their glue) stays in the parent. A linked parent keeps its records,
with a warning, since its other views would lose them too.
**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: