Every sysadmin knows that moment when a DNS zone is completely corrupted and the web panel just isn't responding as expected. Recently, I faced this exact situation. I needed to reset the zones immediately, but traditional DirectAdmin scripts seemed to have been left behind in newer versions.
In this article, I'll detail the errors I encountered and the exact syntax I used to force zone reconstruction via the terminal, without relying on the GUI.
The scenario: when rndc reload isn't enough#
Often, we try the basics: an rndc reload. But if the .db file structure in /var/named/ has syntax errors or inconsistent serials, BIND will ignore the changes. In cases of real corruption, the best path I've found is the Reset (Reserver).
Common error: legacy scripts that vanished#
When searching old forums, I saw many people citing dns_control.sh. However, when trying to run it: bash: /usr/local/directadmin/scripts/dns_control.sh: No such file or directory
DirectAdmin has modernized its structure, and many of these tasks are now centralized in direct calls to the main binary. Attempting to use "guessed" commands on the new binary can also result in Unknown command.
The solution: direct commands in the modern binary#
If you're working with current versions of DirectAdmin, the secret is to use the taskq argument with the --run flag. This puts the task in the daemon's immediate execution queue.
1. Recreating the zone from scratch (reserver)#
The reserver command is what I call the "panic button." It clears the current zone and rebuilds the .db file based on default templates and the IPs linked to the user account. I executed it like this:
/usr/local/directadmin/directadmin taskq --run "action=dns&value=reserver&domain=mydomain.com"2. Forcing the table rewrite#
If the reservation command doesn't generate the physical file for some cache reason, you can force DirectAdmin to specifically rewrite the named service configuration for that domain:
/usr/local/directadmin/directadmin taskq --run "action=rewrite&value=named&domain=mydomain.com"The final step: forcing reading and propagation#
It doesn't matter if the file is perfect on disk if the DNS service doesn't "wake up." Follow this order that I validated in production:
- Syntax Validation: Always check if the recreated file is sound before any reload:
named-checkzone mydomain.com /var/named/mydomain.com.db
- Notify BIND: Notify only the changed zone to avoid overhead:
rndc reload mydomain.com
- Restart Service (Safety): If you feel something is still stuck, a restart is the safest path:
systemctl restart named
Operational troubleshooting checklist#
If the zone still hasn't come up after these steps, I found the culprit is usually one of these:
- File Permissions: The file owner in
/var/named/must be thenamed(orbind) user. If it's set toroot, the service won't read it. - Serial Number: The serial (e.g.,
2026020301) must always be greater than the previous one. Otherwise, Google and Cloudflare will ignore your update. - named.conf Declaration: Ensure the zone is properly declared in your main BIND configuration file.
working with DNS via CLI requires absolute precision. In modern DirectAdmin, centralizing tasks in the taskq --run command is the fastest and most professional way to resolve crises in seconds.
I hope this guide helps you save the time I spent debugging old scripts! If you have any questions or specific cases, let me know in the comments.
Was this article helpful?
Leave a quick reaction to help prioritize future technical guides:
See also
This post is licensed under CC BY-NC.
Comments
Join the discussion below.
0 comments