PD Google Cloud DNS lets a hosting company manage Google Cloud DNS from inside Blesta. Connect a Google Cloud project once and every managed zone in it appears in your admin area with no import. Your customers edit their own records from your client portal, and nobody on your team needs a Cloud Console login for day-to-day DNS.
It is built for hosts and agencies who keep zones in Google Cloud DNS and want to stop sharing console access, answering record-change tickets and copying zone files by hand.
Why hosts choose PD Google Cloud DNS
One service account, no console access to hand out. The provider connects with a service-account JSON key and a project that has the DNS Administrator role. Your staff and customers work in Blesta, not in the Google Cloud Console.
Every project zone, immediately. Zones already in the project are listed the moment you connect, with no import or sync step. The list pages on the server, so it stays quick with hundreds or thousands of zones.
Records live in Google, not in a copy. Reads and writes go to Google Cloud DNS directly, so there is no local cache to drift out of date.
Customers help themselves. Customers add, edit and delete their own records, take and restore snapshots and set up Google Workspace in one click.
Provisioning that follows your orders. Switch on auto-provisioning and a zone is created in your project whenever a domain is registered or transferred, or a service with a domain is set up.
A safety net for every zone. Scheduled BIND-format snapshots run in the background, a restore is one click, and every restore takes a safety snapshot first.
How it works
- Create the service account. In your Google Cloud project, create a service account with the DNS Administrator role and a JSON key.
- Add the provider. Enter the project and the key 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 Blesta packages to set zone allowances, switch on auto-provisioning, and let customers manage their own records.
What you get in Blesta
Connecting and zones
- Add Google Cloud DNS from Providers with a service-account JSON key and the project, which needs the DNS Administrator role
- Test connection says whether the module can reach the project, and what to fix when it cannot
- More than one Google Cloud account or project can be connected and managed in the same interface
- Every zone is listed with no import or sync step, read live from Google Cloud DNS; 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
Selling DNS with your Blesta packages
- Zone allowances: a DNS package caps how many zones a customer may have and is linked to your Blesta packages; 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 Google Cloud DNS
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 portal
- Customers reach their DNS page from My Tools in the client portal menu, and a zone's pages by tabs
- The page saves changes and its links work in Blesta's own client portal theme
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
Every customer string is translatable, and wording overrides survive updates.
Security built in
- The service-account key is stored encrypted, with tamper-evident encryption, in your Blesta database and is never shown back in the provider form.
- The stored credential is used only to read and update zones and records in the connected project.
- Credentials never reach a customer-facing page, and customers' DNS pages and emails never name the backend that serves their DNS.
- To rotate a key, edit the provider, enter the new one, test and save. The old key can then be revoked with nothing else to change.
- Content policy: blocked patterns and IP allow and deny lists refuse matching customer saves; admin changes are never restricted
One product, every feature
PD Google Cloud 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 Blesta 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
- Blesta 6 or later on PHP 8.2 or later, with the ionCube Loader
- A Google Cloud project with Cloud DNS, and a service account with the DNS Administrator role
- PD Modules, the free control panel every PD module installs into
Featured
