adamandClaude Opus 5.5
b24c730b97
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>
128 lines
6.1 KiB
Markdown
128 lines
6.1 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, 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, in two
|
|
groups:
|
|
|
|
```
|
|
$ jarl zone suggest-reverse
|
|
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 # 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
|
|
```
|
|
|
|
**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.
|
|
|
|
## 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 (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:
|
|
|
|
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.
|