v1.3.0 — all four panels verified end to end

All four panels — cPanel/WHM, CyberPanel, DirectAdmin and Plesk — have now been through the same end-to-end round on live servers: account create and remove, addon and alias domains, IDN including an IDN TLD, a main-domain rename, and the queue under an API blocked at the firewall — operations waited with a growing backoff and drained without loss or duplicates once it was lifted. None carries a beta status any more.

Changed behaviour

seconddns sync no longer deletes. It registers what the panel has and SecondDNS does not, and stops there. Removing zones the panel no longer serves is seconddns sync --prune, which refuses when it would drop more than half of a server's zones.

The old behaviour existed only on CyberPanel and had no guard at all: a panel that failed to answer looked exactly like "every domain is gone", and the command would have wiped a customer's zones from the secondary.

One command, on every panel

seconddns — list, status, add, remove, sync, sync --prune, remove-all — now ships with every integration. Previously it existed on CyberPanel alone, with a different set, while the guides told customers to run it everywhere.

Every change goes through the local queue, so it carries retry, FIFO order and the delete-side ownership check.

Defects that made an integration silently non-functional

Each of these was found by running the integration on a real server, and each was enough on its own to stop zones reaching the secondary — without an error anywhere.

• cPanel hooks never fired. The scripts read the event from the top level of the payload; cPanel nests it under data. Finding nothing, they exited successfully.
• Deleting a cPanel account removed nothing. Accounts::Remove carries only the username; every domain of the account is now read from its userdata.
• Addon and alias domains were invisible on cPanel. The installer subscribed to Api2::AddonDomain::addaddon, an event current cPanel does not fire. They arrive through Whostmgr::Domain::park / ::unpark.
• Renaming a main domain lost the zone — on cPanel and on DirectAdmin. The panel fires no DNS create event on a rename, so the old zone was removed and the new one never registered.
• AXFR never worked on cPanel with PowerDNS. The installer wrote allow-axfr-ips and reloaded; a reload rereads the zones, not the server settings. Zones stayed pending and empty.
• The installer broke named.conf on cPanel with BIND. An unbounded insert wrote also-notify into the logging block; named stopped parsing the file, and the installer reported success.
• A master IP that was not an address installed cleanly and failed every zone afterwards with an opaque HTTP 400.
• A server with working IPv6 was configured IPv4-only whenever one echo service did not answer.
• The initial fill queued nothing on DirectAdmin and did not exist on cPanel or CyberPanel.

Safer by default

• every installer verifies the DNS server after touching its configuration, and restores the backup rather than reporting success over a broken service
• the queue worker logs the API's own error text next to a 4xx code
• the server's own hostname zone is no longer offered to the API, which used to leave a failed operation behind on every cPanel install
• a panel with no zones is a legal state: the report and the fill work on a fresh server instead of refusing

Tests and CI

Fifteen test scripts run on every pull request, with a guard that fails the run when a test has no step. They cover the panel installers' address validation, the hook payloads, the rename hooks, the queue, the initial fill, and the named.conf edit against a real cPanel config kept as a fixture.