Requirements

Step 1 — Upload the module

Step 2 — Add your license key

Step 3 — Make the storage folder writable

Step 4 — Activate the addon

Step 5 — Schedule the task runner (important)

Step 6 — Add a DNS server

Step 7 — Create a package

Step 8 — Turn on auto-provisioning

Step 9 — Configure the client experience

Step 10 — Optional power features

Verify it works

Upgrading

Troubleshooting

Uninstalling

Support

A plain-English guide to what DNS Manager is, the ideas it's built on, and how everything fits together.

DNS Manager turns DNS into something you can sell, automate and delegate inside WHMCS. It gives your clients a clean area to manage their own DNS zones and records, gives you full control over what they can do, and connects to 31 different DNS platforms (PowerDNS, Cloudflare, cPanel/WHM, BIND 9, AWS Route 53, Google Cloud DNS, DirectAdmin, Plesk and more) through one consistent interface. Zones are created automatically when a customer orders, and a layer of intelligence — DNS health scoring, propagation checks, and an AI assistant — helps everyone avoid the mistakes that usually become support tickets.

Everything in DNS Manager is built from five simple concepts. Once these click, the whole module makes sense.

   SERVER                 PACKAGE                ZONE                 RECORD
 (where DNS lives)   (rules & limits)     (a domain's DNS)     (one DNS entry)
 ───────────────     ───────────────      ──────────────       ─────────────
 PowerDNS, cPanel,   "VPS DNS": max 5     example.com          www  A  1.2.3.4
 Cloudflare, BIND,   zones, 50 records,   on a Server,         @    MX 10 mail…
 Route 53, …         allowed types …      owned by a client    _dmarc TXT …

                         RECORD SET
                    (a reusable template of records, e.g. "Google Workspace")

• Server — where DNS is actually hosted. A server is one backend (e.g. a PowerDNS box, a Cloudflare account, a cPanel/WHM server). You add as many as you like and DNS Manager talks to each through a driver.
• Package — the rules. A package maps your WHMCS products/addons or domain TLDs to a server, and sets limits: how many zones, how many records per zone, which record types are allowed, the default TTL, and which record set to apply when a zone is created.
• Zone — a domain's DNS (e.g. example.com). A zone belongs to a client and lives on a server. DNS Manager tracks who owns it; the records themselves live on the backend.
• Record — a single DNS entry (A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, PTR…).
• Record Set — a reusable template of records with merge fields like {$domain} and {$ip}, so "set up email" or "point this domain at my server" becomes one click.

Key idea: the zones table is the system of record for who owns what. The records themselves are read from and written to the backend (Cloudflare, cPanel, etc.). The built-in backend is the exception — it stores records in the module's own database, so it works with zero configuration.

DNS platforms all speak different languages — Cloudflare has a JSON API, PowerDNS uses rrsets, cPanel uses WHM API, BIND uses zone files, Route 53 uses signed XML. DNS Manager hides all of that behind a single driver interface. Every backend is a "driver" that implements the same operations (create zone, add record, list records, delete, DNSSEC, reverse DNS). The rest of the module never cares which backend a zone is on.

This means:

• You can run different backends side by side — some zones on PowerDNS, some on Cloudflare, some on a customer's cPanel — all managed from one place.
• Adding a backend in future is a single driver class; nothing else changes.

Each backend is graded so you always know what you're switching on:

You can prove any backend on your own server with the conformance suite (Admin → Servers → Run conformance, or cli.php conformance <id>). It creates a throwaway test zone, runs every operation, checks the round-trips, and cleans up — turning "I hope this works" into "I tested it."

This is the heart of selling DNS. When a customer's order activates, DNS Manager creates their zone for them — no admin action required.

Customer orders a product
        │
        ▼
WHMCS activates the service ──(AfterModuleCreate hook)──► DNS Manager
        │
        ▼
Is a PACKAGE assigned to this product?  ──no──► nothing happens
        │ yes
        ▼
Create a ZONE for the service's domain on the package's SERVER
        │
        ▼
Seed it from the package's RECORD SET (with {$domain}/{$ip} filled in)
        │
        ▼
Zone is live. The customer can now manage it in their client area.

The same happens for domain registrations/transfers (matched by TLD), and zone status follows the service: suspend a service and its zones are flagged; terminate it and (if you enable it) the zones are removed.

You stay in control: provisioning only happens where you've assigned a package, so free trials or products that shouldn't get DNS simply don't.

In the WHMCS client area (under DNS Management), clients can — within the limits you set and only for the features you switch on:

• Create and manage zones (master, and optionally slave zones).
• Edit records with validation (a bad IP or a CNAME-at-apex is rejected with a clear message, not silently broken).
• Bulk actions across many zones at once.
• Apply record sets and build their own.
• Reverse DNS (PTR) management where the backend supports it.
• Backups & restore, and BIND import/export.
• See a DNS Health score for each zone and check propagation.
• Ask the AI assistant to propose changes (which they then confirm).

Every one of these is gated by a setting, so you decide exactly how much self-service to offer.

Under Addons → DNS Manager:

• Dashboard — zone/server/package counts and recent activity.
• Zones — every client's zones; open one to edit records, lock it, migrate it to another server, toggle DNSSEC, import/export BIND, and see its health, drift and audit history.
• Servers — add/edit backends, test connections, run conformance, see maturity badges.
• Packages — the rules that drive provisioning and limits.
• Record sets — global templates you offer to everyone.
• Tasks — the background job queue and its status.
• Audit — every change with a diff and a one-click rollback.
• Deleted zones — restore a removed zone.
• Logs & Settings.

Heavy or repeated work runs in the background so a page load is never blocked. A small script (cron/cron.php) runs every ~5 minutes and processes queued tasks:

WHMCS's own daily cron also prunes old logs and finished tasks.

• DNS Health score (A–F) — analyses a zone for the mistakes that break email and websites: CNAME at the apex, dangling/conflicting records, missing or duplicate SPF, missing DMARC, MX pointing at a CNAME, wildcards, dangerously low TTLs, and duplicates. Each finding comes with a recommendation.
• Propagation checker — asks public resolvers (Cloudflare, Google) and the zone's authoritative nameservers what they see, and reports propagated / partial / pending. This answers the #1 DNS question — "is it live yet?".
• Presets — one-click record sets for Google Workspace, Microsoft 365, generic mail, SPF-hardening, DMARC, CAA (Let's Encrypt) and GitHub Pages.
• AI assistant — describe a goal in plain language ("fix my email deliverability"). The assistant returns a proposed set of changes that is always validated and never applied automatically — a human reviews and confirms. You bring your own model: Anthropic, OpenAI, DeepSeek, Google Gemini, Azure OpenAI, or any OpenAI-compatible/local endpoint (OpenRouter, Groq, Ollama, …). The AI only suggests; DNS Manager's validation and your confirmation are the safety net.

DNS is critical infrastructure, so the module is built to fail safely:

• Per-backend resilience — a token-bucket rate limiter and a circuit breaker protect each backend. If a provider gets unhealthy, its breaker trips and operations fail gracefully with a clear message instead of hammering the API.
• Idempotent writes — adding a record that already exists is a no-op success, so a retried cron run or a double-click never creates duplicates.
• Change audit + one-click rollback — every change is recorded as a diff you can revert.
• Anomaly detection — suspicious changes (apex/NS/MX changes, bulk deletes) are flagged as a DNS-hijack early warning.
• Drift detection — catches records changed directly on the backend, outside the module.
• Safety rails — blocked content strings (plain or regex), IP allow/deny lists, per-package limits, and zone locking.
• RBAC — roles (owner/manager/editor/viewer) with step-up confirmation on destructive actions.

• REST API (api.php) — scoped, owner-bound bearer tokens (zones:read/write, records:read/write, admin). An OpenAPI spec ships in docs/openapi.yaml.
• Webhooks — HMAC-signed events (record added/updated/deleted, anomaly detected) to your endpoints.
• Prometheus metrics (metrics.php) — zone/server/task/record counts and license state for monitoring.
• CLI (cli.php) — list zones/servers, run conformance/drift, issue API tokens, print a zone's health, run the queue.

• Zone identity, packages, servers, record sets, reverse DNS, backups, tasks, audit changes, API tokens and webhooks live in the module's own database tables (prefixed mod_dnsmanager_).
• Record contents live on the backend (Cloudflare, cPanel, …) — except the built-in backend, which stores them in the database.
• Server credentials are encrypted at rest (libsodium) — only decrypted when a connection is made.
• A private storage/ folder (blocked from the web) holds the signed license cache.

DNS Manager is licensed with a key you enter in the module configuration. The license is verified once and then cached, so day-to-day operation never waits on the network. If the licensing server is briefly unreachable, the module keeps working from cache (fail-open) rather than breaking your DNS. Premium features stay enabled while your license is valid.

1. You add a PowerDNS server, click Test (✓), then Run conformance (✓ Verified).
2. You create a package "Hosting DNS" → PowerDNS, 10 zones, 100 records, all types, default TTL 3600, record set "Standard web + mail", assigned to your Web Hosting product.
3. A customer orders Web Hosting for example.com. On activation, DNS Manager auto-creates the example.com zone on PowerDNS and seeds it from the record set (A @→server IP, www CNAME, MX, SPF).
4. The customer opens DNS Management, sees a Health score of B with a tip to add DMARC, clicks the DMARC preset, and the score goes to A.
5. They add an A record for app, then click Check propagation — Cloudflare and Google both already see it: propagated.
6. Later, someone edits the zone directly on the server. The nightly drift task flags it, and you reconcile from the Audit tab.

That's the whole module: servers hold DNS, packages set the rules, zones and records are provisioned and managed automatically, and a layer of health, propagation, AI and safety keeps it all correct.