Summary
go53 backups and WAL exports currently contain sensitive material in cleartext, including DNSSEC private keys, TSIG secrets, and the API authentication key.
While this is documented and operationally acceptable when files remain on the local host, many deployments will archive backups to external storage, object stores, or off-site systems.
Problem
Anyone with access to a backup or WAL archive can:
- Re-sign DNSSEC zones
- Impersonate TSIG-authenticated peers
- Access the administrative API
- Restore or clone a go53 installation
This makes backup archives highly sensitive.
Proposed solution
Add optional encryption support for backup and WAL exports.
Possible approaches:
Option A (preferred)
Passphrase-based encryption using a modern authenticated encryption scheme.
Examples:
- age
- XChaCha20-Poly1305
- AES-256-GCM
Option B
Public-key encryption for backup archives.
Option C
Pluggable encryption provider interface.
Requirements
- Encryption must be optional
- Existing backup format should remain supported
- Integrity protection must be included
- Documentation must clearly describe backup key management and recovery procedures
Release target
Future
Theme
Security / Operations
Summary
go53 backups and WAL exports currently contain sensitive material in cleartext, including DNSSEC private keys, TSIG secrets, and the API authentication key.
While this is documented and operationally acceptable when files remain on the local host, many deployments will archive backups to external storage, object stores, or off-site systems.
Problem
Anyone with access to a backup or WAL archive can:
This makes backup archives highly sensitive.
Proposed solution
Add optional encryption support for backup and WAL exports.
Possible approaches:
Option A (preferred)
Passphrase-based encryption using a modern authenticated encryption scheme.
Examples:
Option B
Public-key encryption for backup archives.
Option C
Pluggable encryption provider interface.
Requirements
Release target
Future
Theme
Security / Operations