adamandClaude Opus 5.5
aa4b004a14
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>
102 lines
4.4 KiB
Markdown
102 lines
4.4 KiB
Markdown
# 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.
|