Reverse zone suggestions: yours and public, dismiss, per-view switch; child zones take their records
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>
This commit is contained in:
1 parent
aa4b004a14
commit
b24c730b97
21 files changed
+543
-107
No files matched your search
+2
-1
@@ -361,7 +361,8 @@ and `linked_with` (the other views).
|
||||
| POST | `/zones/{zone}/link` | `{"with": ["external"]}` (default: every view with that zone). Names and types that are the same everywhere become shared, the rest stay local |
|
||||
| POST | `/zones/{zone}/unlink` | Takes the zone out of its link; its records stay, all local |
|
||||
| POST | `/zones/{zone}/fill-ptr` | Adds the PTR records a reverse zone lacks for its view's A and AAAA records ([reverse.md](reverse.md)) |
|
||||
| GET | `/reverse-zones/suggestions` | The reverse zones the private views lack: `view_id`, `view`, `prefix`, `zone`, `why`, `fill` (PTR records it would get), `samples` |
|
||||
| GET | `/reverse-zones/suggestions` | The reverse zones the private views lack: `view_id`, `view`, `prefix`, `zone`, `group` (`yours`, or `public`: only if the address is yours), `why`, `fill` (PTR records it would get), `samples` |
|
||||
| POST | `/reverse-zones/dismiss` | `{"view": "internal", "prefix": "185.199.108.153/32"}`: don't suggest it again (`/undismiss` brings it back). A view's `reverse_suggestions: false` (PATCH `/views/{id}`) stops its suggestions |
|
||||
| GET | `/zones/{zone}/compare` | The zone across the views that have it (`?views=a,b`; `?all=1` also the same rows): `views`, `linked`, `same` (count) and `rows` (name, type, `same`, per view `records`, `ids`, `linked`). The zone may be named without a view |
|
||||
|
||||
`POST /zones` takes `"link_with": "VIEW"` to create a zone linked with
|
||||
|
||||
+3
-1
@@ -179,7 +179,9 @@ jarl zone create 10.0.8.0/22 # four zones, 8-11.0.10.i
|
||||
jarl zone create 10.0.10.100/32 # a zone for just that address
|
||||
jarl zone create 10.0.10.0/24 --fill # in the view whose records use it, with their PTRs
|
||||
jarl zone fill-ptr 10.0.10.0/24 # add the PTRs it lacks (zone commands take a network too)
|
||||
jarl zone suggest-reverse [--create] # reverse zones your private views lack
|
||||
jarl zone suggest-reverse [--create] # reverse zones your private views lack (--create: yours)
|
||||
jarl zone suggest-reverse --dismiss 185.199.108.153/32 --view internal # not yours: don't suggest it again
|
||||
jarl view update vps --reverse-suggestions=false # no suggestions for this view
|
||||
jarl zone update adbraun.lol --auto-ptr # keep PTRs in step with the A/AAAA records (docs/reverse.md)
|
||||
jarl zone create adbraun.lol --view external --clone-from adbraun.lol --clone-view internal
|
||||
jarl zone create partner.example --type secondary --primary "192.0.2.53 key xfer"
|
||||
|
||||
+2
-1
@@ -260,7 +260,8 @@ boundary. So:
|
||||
|
||||
Jarl suggests the reverse zones your private views lack, creates them in
|
||||
the right view filled with PTR records, and can keep PTR records in step
|
||||
with a zone's A and AAAA records: [reverse.md](reverse.md).
|
||||
with a zone's A and AAAA records: [reverse.md](reverse.md). A zone created
|
||||
inside another (a /24 inside a /8) takes the parent's records under it.
|
||||
|
||||
### Dynamic updates and TSIG keys
|
||||
|
||||
|
||||
+45
-19
@@ -19,32 +19,49 @@ Who asks matters:
|
||||
delegated it to you.
|
||||
|
||||
So reverse zones belong in private views. A view whose clients reach it
|
||||
from the internet gets no suggestions.
|
||||
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, with
|
||||
**Create** (or **Create all**):
|
||||
private view lacks for the addresses of its A and AAAA records, in two
|
||||
groups:
|
||||
|
||||
```
|
||||
$ 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, ...
|
||||
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 # all of them, filled, in one changeset
|
||||
$ 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
|
||||
```
|
||||
|
||||
* 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`).
|
||||
**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.
|
||||
@@ -57,9 +74,18 @@ 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.
|
||||
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:
|
||||
|
||||
Reference in new issue
Block a user