jarl/docs/reverse.md

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

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:

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