# 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.