adam/jarl
1
0 Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 34 Wiki Activity

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

Browse Source 
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>
This commit is contained in:
adamandClaude Opus 5.5 committed 2026-10-12 21:23:59 +01:00
1 parent a3b054cc86
commit aa4b004a14
27 files changed
+1173 -38
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/api.md
+9
View File
@@ -190,6 +190,7 @@ ZoneInput:
```json
{
"name": "adbraun.lol", // or a CIDR like "192.168.1.0/24" for a reverse zone
"fill": true, // reverse zones: PTR records for the view's A/AAAA records there
"view": "internal", // or "view_id"; moving a zone = PATCH with another view
"type": "primary", // secondary, stub, static-stub, forward, mirror, hint, redirect, in-view
"in_view": "internal", // type in-view only
@@ -199,6 +200,7 @@ ZoneInput:
"default_ttl": 3600,
"serial_policy": "date", // date, increment, unixtime
"dnssec_policy": "default", // primary zones: "" (off), "default", a custom policy, "insecure" (turning off)
"auto_ptr": true, // keep the PTRs of the zone's A/AAAA records in step (docs/reverse.md)
"comment": "",
// create only:
"nameservers": ["ns1.adbraun.lol."], // default: settings
@@ -208,6 +210,11 @@ ZoneInput:
}
```
A reverse zone created without a view goes to the private view whose
records use its addresses. Zones come back with `prefix` (reverse zones:
the network) and `ptr_missing` (addresses in it that the view's A and AAAA
records use, without a PTR record).
`/serials` and `/delegation` send DNS queries from the server, and only
when called ([operations.md](operations.md#checking-name-servers-and-the-delegation)).
`/serials` works for primary, secondary and mirror zones:
@@ -353,6 +360,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 | `/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
docs/cli.md
+4
View File
@@ -177,6 +177,10 @@ jarl zone create lab.adbraun.lol --ns ns1.adbraun.lol.
jarl zone create 192.168.20.0/24 # reverse zone from a network
jarl zone create 10.0.8.0/22 # four zones, 8-11.0.10.in-addr.arpa
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 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"
jarl zone create consul --type forward --forwarder "127.0.0.1 port 8600"
docs/concepts.md
+4
View File
@@ -258,6 +258,10 @@ boundary. So:
(RFC 2317 delegation, where an ISP hands you part of a /24, is set up by
hand with CNAMEs.)
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).
### Dynamic updates and TSIG keys
Jarl writes every zone file, so it can't let named change a zone through
docs/reverse.md
+101
View File
@@ -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.