PD BIND 9 DNS — BIND 9 Zone & Record Management for WHMCS
Manage your BIND 9 DNS zones and records inside WHMCS — fast, self-service, auto-provisioned
Made and supported by Projektif Digital Ltd.
Runs inside PD Modules, the panel
every module installs into.
Domains & DNS
Connect your BIND server in one step — encrypted SSH key, zone directory, and authoritative nameservers stored once, then every zone loads automatically with no per-zone setup.All zones from your BIND server in one searchable list — filter by client or status, see record counts at a glance, and jump straight into records in one click. Server-side pagination keeps it fast at any scale.Live zone records managed without leaving WHMCS — colour-coded type badges, inline search, and one-click edit. Every save goes through named-checkzone before it touches the live zone file.Select a record type and exactly the right fields appear — an MX record shows Priority and Mail server; an SRV record shows all four fields. Built-in validation and a trailing-dot reminder mean a bad record is caught at the form, not after it reaches BIND.Your customers manage their own DNS inside the WHMCS client portal — zone list with status badges and a direct link to their records, no support ticket needed. Renders on every bundled WHMCS theme.Full DNS record editor in the client area — customers add and edit any record type with the same type-aware form your team uses, every write validated by named-checkzone in real time.1 / 6
PD BIND 9 DNS lets a hosting company manage its own ISC BIND 9 name servers from WHMCS. The module connects over SSH, reads your zone files into a searchable list with no import, and writes every change back safely: each edit is validated with named-checkzone before it can replace a live zone file. Your customers edit their own records from your client client area, with no shell access to the server.
It is built for hosts who run their own authoritative BIND servers and want a proper control panel for them, so DNS changes stop being a job for the person with root.
Why hosts choose PD BIND 9 DNS
A bad record cannot break your zone. Every write is checked with named-checkzone on a temporary copy before it replaces the live zone file. The serial is bumped and the zone reloaded with rndc, so an invalid change never reaches the zone.
No new accounts or API keys. The module connects with an SSH private key or a password, to the server you already run. Your staff and customers work in WHMCS and never touch the server.
Reverse DNS included. Add an IP range, map addresses to hostnames, and each PTR record is written to the matching reverse zone on your server.
Customers help themselves. Customers add, edit and delete their own records and restore their own snapshots, with the same validation your team gets.
How it works
Prepare SSH access. Give the module a user that can read and write your zone files and run rndc, with an RSA private key or a password.
Add the provider. Enter the connection details and your authoritative nameservers in Providers and press Test connection. Your zones appear straight away.
Link zones to clients. Assign zones with the client picker, or press Track matched zones to bind every zone that matches an active domain or service.
Sell and support it. Link DNS packages to your WHMCS products to set zone allowances, switch on auto-provisioning for new domains, and let customers manage their own records.
What you get in WHMCS
Connecting and zones
Connect over SSH with an RSA private key or a password. Ed25519 and ECDSA keys are not supported, and the docs say so up front
Test connection says whether the module can reach the server, and what to fix when it cannot
More than one BIND server can be connected and managed in the same interface
Creating a zone writes its zone file with SOA and NS records taken from your authoritative nameservers. Adding the zone block to named.conf stays your step as the server owner
Secondary zones can be created from master IPs; their records are read-only
Every zone is listed with no import or sync step, read live from your BIND 9 server; changes are written straight back and the module keeps no copy of your records
Server-side paging, search and sort keep the list fast with thousands of zones; narrow it by name, provider, status or client
Track matched zones binds every zone matching an active domain or service to its client in one step, changing nothing at the provider
Lock a zone against the client's own changes; admins keep full control and the client keeps read access
Records
A type-aware editor that shows only the fields the type uses: priority and mail server for MX, priority, weight, port and target for SRV, flags, tag and value for CAA
Addresses and hostnames are checked before saving, so a malformed record never reaches the provider. Search by name or value and filter by type
Export a zone as a BIND zone file. Import adds only missing records and shows how many before it writes anything
Every write: lock, read, change, bump the serial, check with named-checkzone, promote, reload with rndc. If the check fails, the live zone file is never touched
Selling DNS with your WHMCS products
Zone allowances: a DNS package caps how many zones a customer may have and is linked to your WHMCS products; the largest allowance wins
Record limits per zone and per record type, held in the customer's editor, imports, templates and the API
Templates: apply a named set of records to any zone in one click, with merge fields such as {domain}, {ns1} and {ip}; applying twice is safe
Auto-provision, off until you switch it on: a zone is created and bound to the client when a domain is registered, transferred or set up with a service. A failure is logged and never interrupts the order
TLD takeover: for the extensions you choose, a newly registered or transferred domain also gets its nameservers pointed at your BIND 9 server
Reverse DNS: add an IP range, then map addresses to hostnames; each PTR is written to the matching reverse zone on your server
Running it day to day
Backups on by default: every zone is snapshotted as a BIND zone file each 24 hours, keeping the newest 10, with settings for both and an optional age cap. Back up one zone or all on demand
Restore makes a zone match a snapshot exactly, after a safety snapshot; a zone deleted by mistake is recovered with every record
Optional emails, off until you turn them on: admin alerts for drift or a failed backup, and customer notices when a zone is created, removed or changed by staff
A REST API with named read or write tokens and optional source-IP limits. Tokens are shown once and stored hashed, and writes pass the same checks as the panel. Every API write is logged in Activity
In your client area
A Manage DNS link on a client's domain and service pages whenever that domain or service has a zone, plus a navigation link whose text and place you choose
The link can replace the registrar's DNS Management link, sit beside it, or be left out; a zone's pages use sidebar links, tabs, or either alone
What your customers get
Their own zones, and only theirs. A customer sees and changes only zones bound to their account. This is enforced on the server, not just hidden in the page
The same editor your team uses. Add, edit and delete records in their own zones with the validating, type-aware form, written straight to the provider
Snapshots they control. With client backups on, customers snapshot their zone, download any snapshot and restore one, with a safety snapshot first. Turn it off to keep backups admin-only
One-click set-ups. Quick set-ups add the records Google Workspace or Microsoft 365 needs, or an SPF lockdown, without changing anything already there
Read-only where you say so. A locked zone is view-only, and for a domain with no hosting here you choose full editing, view only or hidden
The customer's Manage DNS page in your client area: their zones, each with a Manage records button
Pages render natively on WHMCS's Six, Twenty-One and Nexus themes and are fully translatable, with wording overrides that survive updates.
Security built in
Your SSH private key or password is stored encrypted, with tamper-evident encryption, in your WHMCS database and is never shown back in the provider form.
The stored credential is used only to read and update zones and records on the connected server.
Credentials never reach a customer-facing page, and customers' DNS pages and emails never name the backend that serves their DNS.
Use a dedicated system account for the module rather than root, so it can only do what DNS management needs.
Content policy: blocked patterns and IP allow and deny lists refuse matching customer saves; admin changes are never restricted
One product, every feature
PD BIND 9 DNS is one paid module with everything included: zones, records, backups, templates, packages, auto-provisioning, the API and customer self-service. There are no add-on tiers to compare, and beyond the subscription there is no per-zone, per-seat or per-unit fee. It installs into PD Modules in one click, adds its own tables and templates, modifies no WHMCS files, and removes everything on uninstall. This module does not sign zones or manage DNSSEC keys, and offers no DNSSEC control.
Your customers are not cut off if your subscription lapses. DNS records are never touched and the provider keeps serving your zones. Admin management locks first while customers keep their own self-service; customer management stops later behind a neutral "temporarily unavailable" message, and renewing restores everything.
Requirements
WHMCS 9 or later on PHP 8.2 or later, with the ionCube Loader
A BIND 9 server you can reach over SSH, with named-checkzone and rndc available
PD Modules, the free control panel every PD module installs into
Questions
Does PD BIND 9 DNS store my DNS records?
No. Your BIND 9 server remains the single source of truth. The module reads records live from your zone files over SSH and writes changes straight back to them. The only things kept in your WHMCS database are metadata — zone ownership, backup snapshots and activity logs. There is no local copy of your records to drift out of sync.
What kind of BIND server and access does it need?
A running ISC BIND 9 server that is reachable over SSH from your WHMCS server. It connects with an SSH user that can read and write your zone files and run rndc and named-checkzone. Because a non-login SSH shell often has a minimal PATH, you provide the full paths to rndc and named-checkzone so the module can always find them.
How does it connect, and is my key safe?
You connect once over SSH — no new API keys and no third-party accounts. An SSH private key is preferred (a password also works). The key is stored encrypted in your WHMCS database, shown masked in the interface and never exposed through the module. Your team does day-to-day DNS work inside WHMCS without anyone needing shell access to the BIND server.
How does it make sure a record change won't break my zone?
Every change is an atomic write: lock the zone, read the current file, bump the SOA serial, validate the result with named-checkzone, promote it, then run rndc reload. If named-checkzone rejects the change, it is discarded and your live zone file is never touched. A typo cannot take a zone down.
Why do I have to configure authoritative nameservers?
When the module creates a new zone, it needs valid SOA and NS records to write. Your configured authoritative nameservers become the zone's SOA MNAME and its NS records, so every new zone is served correctly by your own name servers from the moment it is created. It is a required part of setup for this reason.
Is DNSSEC supported?
No. PD BIND 9 DNS does not sign zones or manage DNSSEC keys. If you need signed zones, keep signing them with your own BIND tooling (for example dnssec-policy on your server) — the module manages your record data and leaves DNSSEC key management to BIND.
Can it manage secondary (slave) zones?
Yes. The module can add a secondary zone block to your configuration and run rndc reconfig so your BIND server starts serving the slave zone. This is handy when you run BIND as a secondary for zones that are primary elsewhere.
What record types can I manage?
A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, PTR, TLSA, SSHFP and NAPTR, each with a type-aware editor that checks addresses and hostnames before saving.
Can it create zones automatically when a domain is registered?
Yes. A DNS zone can be created on your BIND server automatically when a customer registers or transfers a domain or orders a service — each new zone gets a valid SOA and NS block from your authoritative nameservers, validated by named-checkzone and reloaded. Separately, the TLD takeover list on your provider names the extensions whose nameservers are also pointed at your BIND server when such a domain is registered or transferred (registrar modules that support nameserver changes).
What happens to my zones if the subscription lapses?
Your DNS records are never touched. Zones stay exactly as they are on your BIND server and keep resolving without interruption. A lapsed subscription only withdraws admin management and customer self-service inside WHMCS — everything resumes as soon as the subscription is renewed.
What does it cost to run, on top of the subscription?
Only what you already pay your provider. PD BIND 9 DNS adds no per-unit fee and takes no cut — it connects to your own account with your own credentials, so the provider bills you directly at your rates, and you set what you charge your customers. From us it is the module subscription and nothing else.
Which WHMCS and PHP versions does it need?
WHMCS 9 or later, on PHP 8.2 or later. It installs alongside whatever else you run — it adds its own tables and templates rather than modifying WHMCS files, so it does not collide with other vendors' modules or with a customised theme. Uninstalling removes its own tables and settings and leaves no orphans behind.
Featured
