dnz replication.
DNZ to DNZ
The easy way: one DNZ is the primary, the others join it. A joined secondary follows the primary’s catalog zone (RFC 9432), so every zone you add or delete on the primary appears or disappears on the secondary by itself. DNSSEC keys are copied too (with their rollover state and the zone’s signing settings; only the primary rolls keys), so both servers sign with the same keys and the one DS record at your registrar covers them. There are two ways to join.Find it on the network
- Dashboard
- CLI
1
Look for the primary
On the secondary, open DNS → Replication → Join a primary. The On this network
tab shows a radar of the DNZ servers it finds.
2
Pick it
Click the primary. The secondary shows a 6-digit code.
3
Approve on the primary
On the primary, the request appears under Waiting to join with the same code. Check
that the codes match, then click Approve.
4
Done
The secondary receives its credentials and starts copying zones.
_dnz._tcp) and by probing the local private subnets
for /api/info on ports 8080, 443, 80 and 8443 (up to a /22 per interface).
Join requests expire after 10 minutes. At most 20 can wait at once.
Join code
- Dashboard
- CLI
1
Create a code on the primary
On the primary, click Add secondary → DNZ server. Give it a name and check This
server’s address (where the secondary reaches the primary’s web UI). You get a join code
that starts with
dnz-join:.2
Use it on the secondary
On the secondary, open Join a primary → Join code, paste it, and pick the division
the zones go to.
What a joined secondary does
- It asks the primary’s HTTPS/HTTP API once for its TSIG key and the catalog name
(
/api/replication/bootstrap), then uses DNS for everything else. - It transfers the catalog
catalog.dnz.invalid., adds a secondary zone for each member, and removes the ones that left. A member whose name already exists here as a local zone is not touched; the subscription shows a conflict instead. - After each change it fetches the DNSSEC keys of signed zones (
/api/replication/keys). - The primary sends NOTIFY to the address the secondary joined from, on its DNS port.
dnz replication leave 1) stops following the primary and
deletes the zones copied from it.
DNZ as primary for BIND, Knot or PowerDNS
Add secondary → Other nameserver creates a TSIG key for it and shows ready-to-paste configuration for BIND 9.18+ and Knot DNS. Both follow the catalog zone, so new zones show up there without editing their config. Fill in:- Transfers allowed from: optional addresses or networks. With Require TSIG off, this list is the only check, so it’s required then.
- Send NOTIFY to: where to send NOTIFY (port 53 unless given). Without it, the secondary picks up changes at its SOA refresh interval (1 hour).
options and as a zone:
named.conf
Zones are transferred without signatures, because DNZ signs answers online. A non-DNZ secondary
therefore serves them unsigned. For signed zones, use DNZ secondaries (they share the key), or
sign on the secondary with its own key and add its DS too. See DNSSEC.
DNZ as secondary of any primary
Secondary zone (in Copied from other primaries) copies one zone from any primary. Give:- the zone name,
- the primary’s addresses (tried in order),
- if the primary needs it, the TSIG key name, algorithm (hmac-sha256, hmac-sha384 or hmac-sha512) and base64 secret.
How secondary zones behave
- They’re read-only: records, import, DNSSEC and Dynamic DNS/ACME tokens only work on the primary. The zone page shows the primary, the last transfer, when the copy expires, and any error.
- DNZ checks the primary’s SOA serial at the SOA refresh interval (clamped to 1 minute – 1 day),
after a NOTIFY, or when you click Refresh. A higher serial (RFC 1982 arithmetic) triggers a
full transfer. Transfer again transfers even if the serial didn’t change
(
dnz zone refresh example.org --full). - After a failed check it retries at the SOA retry interval.
- If the primary can’t be reached for longer than the SOA expire time (at least 1 hour), the zone answers SERVFAIL instead of serving stale data. It answers again after the next successful transfer.
- DNSSEC records from a presigned primary (RRSIG, NSEC, NSEC3, DNSKEY) are not stored; DNZ signs online with its own or the shared key.
- Secondary zones never forward names they don’t have (see Forward missing names).
How DNZ answers transfers
- AXFR and IXFR over TCP only (UDP is refused). IXFR from a secondary that’s already current gets just the SOA; otherwise the whole zone is sent as AXFR (RFC 1995 allows this).
- A transfer is allowed when the request is signed with a secondary’s TSIG key and comes from one of its allowed addresses (if any), or, for secondaries without TSIG, when it comes from an allowed address. Anything else is REFUSED; a wrong signature gets a signed BADSIG/BADKEY answer.
- Large zones are split into messages of about 16 KB, each signed (TSIG over the whole stream).
- The catalog serial goes up whenever a primary zone is added or removed; zones keep their own serials, which change with every record edit. Both trigger NOTIFY to all secondaries, retried three times.
- A disabled zone counts as removed: it leaves the catalog (secondaries following it drop the zone) and transfers of it are refused with NOTAUTH until it is turned on again. Disabled records are left out of transfers.
- Only a zone’s default records are transferred, never view records.
Test with dig
DNSSEC
One DS for every DNZ nameserver.
CLI: replication
Every replication command.