These are the 28 public choices in the audited build, counting the three PowerDNS variants separately. Select the exact choice offered by the installed release. A local database storage backend is not itself a public authoritative DNS service.

Start with the zones and accounts you control. For an existing provider, using its correct driver preserves the relationship between the zone and the account authorised to manage it. If you are building a new service, compare the DNS features you need, provider permissions, operating costs and recovery arrangements.

Record editing, zone creation, DNSSEC, reverse DNS and secondary-zone support are separate capabilities. A vendor may offer a feature that your account, API credential or specific zone does not permit. Configure package controls around the capabilities actually available.

You can add more than one connection, including multiple accounts with the same provider. A DNS package can select several servers and one master for management and synchronization. This does not automatically make every listed server an authoritative nameserver at the registry.

Check the record-type intersection before replicating a package across different systems. Provider-specific proxy settings, DNSSEC keys, forwarding infrastructure and hosted websites do not become portable DNS records merely because the record set is synchronized.

Connect the provider, assign a test package and verify the operations you intend to sell. Document customer-visible limitations from the actual package and backend. Avoid describing a provider as unsupported merely because your first installation used a different provider; equally, avoid promising every vendor feature through the module without checking the current driver.

• Add a DNS provider connection and prove that it can manage zones
• Synchronize a DNS package across multiple servers and select its master
• Build a DNS package for hosting products, addons and domain TLDs
• Operate DNSSEC from zone signing through parent DS verification