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.

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

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:

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.