Repository navigation
Restart PowerDNS instead of reloading it, and notice when it stays down - #89
Conversation
On the live cPanel box the zone reached SecondDNS, the worker created it on
ns3, and then sat at pending forever:
08:57:12 done queue=pdns.zone-add zone=my123domain.com
08:57:12 notify empty, staying pending
AXFR was refused. The installer had written allow-axfr-ips into pdns.conf and
run `systemctl reload pdns` — and a reload rereads the zones, not the server
settings. The setting sat in the file with no effect until something restarted
the service. A customer would see zones registered in SecondDNS and empty on
the secondary, with nothing to explain it.
Proven in place: `dig AXFR` refused after the reload, the same query answered
after `systemctl restart pdns`, and my123domain.com moved pending -> synced
within seconds. cPanel was the only installer using reload; CyberPanel and
DirectAdmin already restart.
Writing the guard turned up a second one: DirectAdmin restarted PowerDNS and
reported success without checking it came back, so a config it could not parse
would leave DNS down under a "[+] configured and restarted". It now verifies
and restores the backup, as CyberPanel does.
tests/test_pdns_restart.sh asserts, for every installer that touches pdns.conf:
no reload, a restart, a message when it stays down, and a rollback to the
backup. Lower bound of 3 installers so a rename fails instead of matching
nothing. Mutations: restoring the reload fails 1, dropping the down-message
fails 2, dropping the rollback fails 1.
|
Ready to merge. Verified: cPanel and DirectAdmin now restart PowerDNS (a reload re-reads zones, not allow-axfr-ips), check liveness after it, and on failure restore the timestamped backup and restart again rather than report success over a dead resolver; CyberPanel already carried the same restart-and-check; Plesk is BIND, where rndc reload does apply allow-transfer. The test asserts behaviour (no reload verb, a restart, a liveness check, a rollback) rather than one panel's wording, and the two false-green versions you named are gone. Live proof — Transfer failed after reload, full zone after restart, pending→synced — is in the body. CI green, no attribution trailers, comments within two lines. |
|
Verified after the rebase: MERGEABLE, CI green on the merged state (thirteen tests), no attribution trailers, comments within two lines. Ready to merge into develop. |
1 participant
The first zone created through the live cPanel box never arrived. It reached SecondDNS, the worker created it on ns3, and then:
AXFR was being refused. The installer had written
allow-axfr-ipsintopdns.confand then runsystemctl reload pdns— and a reload rereads the zones, not the server settings. The line sat in the file doing nothing until something restarted the service.What a customer would have seen: zones registered in SecondDNS, permanently
pending, empty on the secondary, and an installer that reported[+] PowerDNS reloaded.Proven in place
and the zone moved
pending → syncedwithin seconds of the restart.cPanel was the only installer using
reload; CyberPanel and DirectAdmin already restart.A second one, found by the guard
DirectAdmin restarted PowerDNS and printed
[+] PowerDNS configured and restartedwithout checking it came back. A config it could not parse would leave DNS down under a cheerful message — the same shape as the CyberPanel restart-loop found earlier this cycle. It now verifies the service and restores the backup if it did not.Tests
tests/test_pdns_restart.sh, for every installer that touchespdns.conf: no reload anywhere, a restart present, a message when the service stays down, and a rollback to the backup. Lower bound of 3 installers, so a rename fails here instead of matching nothing and passing.Mutations: restoring the reload fails 1, dropping the "did not come back" message fails 2, dropping the rollback fails 1.
Two notes on writing it: the first version of the liveness check matched
pgrep -x pdns_serveranywhere in the file — which the backend detection also uses, so a mutation removing the real check still passed. And the rollback check was written against one installer's spelling; CyberPanel restores through${PDNS_CONF}.bak.$BACKUP_STAMPrather than$PDNS_BAK, which is the same behaviour. Both criteria now describe the behaviour instead of one panel's wording.