0045: Keel DNS, PowerDNS authoritative

**Decision (maintainer, 2026-10-02).** Keel DNS is a new appliance on Keel Core running PowerDNS Authoritative. It is authoritative for the zones it serves, which sets it apart from every other appliance. Health checked answers use PowerDNS's built in LUA records (`ifportup`, `ifurlup`), so a name resolves only to live nodes. At least two authoritative servers in different sites (0025 site rule). It fills 0024's open item: nodes behind NAT with changing IPv6 prefixes update their own records by RFC 2136 dynamic update with TSIG, or through the etcd registry. It serves the public on 53/udp and 53/tcp, has no Keel Web in front, its exposure class is public, and it is the first appliance whose failure affects all the others. **Package facts** (trixie, 2026-10-02): `pdns-server` 4.9.17-0+deb13u1, every `pdns-backend-*` at the same version, `pdns-tools` 4.9.17-0+deb13u1, `dnsdist` 1.9.16-0+deb13u1, `bind9-dnsutils` (nsupdate) 1:9.20.29-1~deb13u1. LUA records verified in the trixie binary: `enable-lua-records`, `lua-health-checks-interval`, `ifportup`, `ifurlup`; RFC 2136 through `allow-dnsupdate-from`, `TSIG-ALLOW-DNSUPDATE` and `lua-dnsupdate-policy-script`; `default-catalog-zone` present. **Handbook:** `docs/decisions/0045-keel-dns-powerdns-authoritative.md` (handbook#38) **Amends:** 0020 (DNS with a health check becomes an appliance, not a Keel Cloud piece), 0024 (its open DNS item decided), 0028 (primary and replica as DNS primary and secondary), 0029 (Keel DNS is not behind the VIP; its redundancy is NS records in different sites). **Open questions** (recommendations in the note) - [ ] Backend: `gsqlite3` local per server with NOTIFY, zone transfer and catalog zones; the etcd feed writes into the primary through the API, never a live etcd backend - [ ] Low TTL: 60 s on health checked records, floor 30 s, 3600 elsewhere - [ ] DNSSEC: not in the first version; its own note - [ ] Node updates: etcd in cloud advanced, RFC 2136 with TSIG per node elsewhere, limited to the node's own names - [ ] Abuse of public 53: no front in version 1; dnsdist as a later overlay if needed - [ ] Second server: always the operator's; Keel Cloud may offer one **First tasks** (after Phase 3, before Phase 5; the registry feed in Phase 5) - [ ] `keel-overlay-pdns`: PowerDNS from trixie, `gsqlite3`, LUA records on, manifest with 53/udp and 53/tcp public and a Monit `protocol dns` check - [ ] `keel-dns` appliance on Core, simple mode; zones and health checked names in the spec, rendered by keel - [ ] Cloud simple: primary and replica by NOTIFY, transfer and a catalog zone over the mesh; RFC 2136 with TSIG from mesh addresses only - [ ] Gate: two servers on different bridges; a stopped Keel Web node leaves both servers' answers within a check interval plus the TTL; a node's TSIG is refused for another node's name - [ ] Phase 5: the feed from the etcd registry, cloud advanced on three sites

marcos-mendez commented

2026-10-02 00:06:52 -03:00

(Migrated from github.com)

Decision (maintainer, 2026-10-02). Keel DNS is a new appliance on Keel Core running PowerDNS Authoritative. It is authoritative for the zones it serves, which sets it apart from every other appliance. Health checked answers use PowerDNS's built in LUA records (ifportup, ifurlup), so a name resolves only to live nodes. At least two authoritative servers in different sites (0025 site rule). It fills 0024's open item: nodes behind NAT with changing IPv6 prefixes update their own records by RFC 2136 dynamic update with TSIG, or through the etcd registry. It serves the public on 53/udp and 53/tcp, has no Keel Web in front, its exposure class is public, and it is the first appliance whose failure affects all the others.

Package facts (trixie, 2026-10-02): pdns-server 4.9.17-0+deb13u1, every pdns-backend-* at the same version, pdns-tools 4.9.17-0+deb13u1, dnsdist 1.9.16-0+deb13u1, bind9-dnsutils (nsupdate) 1:9.20.29-1~deb13u1. LUA records verified in the trixie binary: enable-lua-records, lua-health-checks-interval, ifportup, ifurlup; RFC 2136 through allow-dnsupdate-from, TSIG-ALLOW-DNSUPDATE and lua-dnsupdate-policy-script; default-catalog-zone present.

Handbook: docs/decisions/0045-keel-dns-powerdns-authoritative.md (handbook#38)

Amends: 0020 (DNS with a health check becomes an appliance, not a Keel Cloud piece), 0024 (its open DNS item decided), 0028 (primary and replica as DNS primary and secondary), 0029 (Keel DNS is not behind the VIP; its redundancy is NS records in different sites).

Open questions (recommendations in the note)

Backend: gsqlite3 local per server with NOTIFY, zone transfer and catalog zones; the etcd feed writes into the primary through the API, never a live etcd backend
Low TTL: 60 s on health checked records, floor 30 s, 3600 elsewhere
DNSSEC: not in the first version; its own note
Node updates: etcd in cloud advanced, RFC 2136 with TSIG per node elsewhere, limited to the node's own names
Abuse of public 53: no front in version 1; dnsdist as a later overlay if needed
Second server: always the operator's; Keel Cloud may offer one

First tasks (after Phase 3, before Phase 5; the registry feed in Phase 5)

keel-overlay-pdns: PowerDNS from trixie, gsqlite3, LUA records on, manifest with 53/udp and 53/tcp public and a Monit protocol dns check
keel-dns appliance on Core, simple mode; zones and health checked names in the spec, rendered by keel
Cloud simple: primary and replica by NOTIFY, transfer and a catalog zone over the mesh; RFC 2136 with TSIG from mesh addresses only
Gate: two servers on different bridges; a stopped Keel Web node leaves both servers' answers within a check interval plus the TTL; a node's TSIG is refused for another node's name
Phase 5: the feed from the etcd registry, cloud advanced on three sites

Rows
Columns

0045: Keel DNS, PowerDNS authoritative #50