Use DNS → Packages to define the DNS allowance linked to your Blesta packages. These module limits describe what a customer may manage; they do not raise the limits of your provider account.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

Administrative bulk jobs and replication write directly to the provider. Customer editing locks, allowances, content rules and forwarding-record protections must not be assumed to stop these operations. Your hosting team must review the target zones and exclude records owned by another feature before running them.

Define an allowance

1. Open DNS → Packages and create a recognisable package.
2. Set the zone allowance and records-per-zone cap.
3. Add any per-record-type maximum and default TTL needed for that offering.
4. Link the package to the intended Blesta packages using the picker.
5. Enable it and review the linked active service before relying on enforcement.

A default TTL pre-fills the editor; it is not an instruction to rewrite all TTLs already published. A record-type cap is also separate from the total records-per-zone limit. Review the meaning of zero/unlimited values in the form before saving.

Check the customer’s effective limit

The released allowance logic considers applicable packages from active services. Finite limits use the largest applicable allowance rather than adding every service’s quota together. An applicable unlimited allowance removes that finite cap.

Use a controlled customer/service when checking entitlement. Confirm the zone is assigned to the intended owner and that the service uses the product/package you linked. An unowned zone or an unmatched entitlement should not be used as proof that a customer limit is working.

Diagnose a refused write

Compare the current zone/record count, the effective module allowance and the provider’s own quota. A provider rejection is not corrected by increasing only the module allowance. A lock, content rule or managed-record protection needs its own diagnosis too.

Do not delete live records simply to make a cap warning disappear. Review whether the configured offering matches the service sold, then make the appropriate setting change. Disabling a package stops its enforcement without being a request to remove DNS data. See the content-policy guide and zone ownership guide for the other common causes.

See the PD DNS Manager Blesta guide for related tasks, or explore the module.