Skip to content

Knowledgebase

Connect the PowerDNS Authoritative API to Domain Nexus

domain-nexus, development

Connect Domain Nexus to the HTTP API of PowerDNS Authoritative Server. The API endpoint is separate from the public nameserver addresses that customers enter at their registrar. A DNS query sent to port 53 and an authenticated API request perform different jobs.

Which PowerDNS service and backend can accept API writes?

Enable the Authoritative Server API and configure its API key using the supported settings for your PowerDNS release. Restrict network access to the administration endpoint and provide HTTPS through your approved deployment arrangement. Confirm that the selected backend supports the writes and DNSSEC operations you plan to use. A readable BIND backend does not supply the same writable API workflow as a suitable database backend.

01 Configure the connection

  1. Add a Domain Nexus server and select PowerDNS.
  2. Enter the API origin in API URL, including any approved reverse-proxy prefix. The adapter appends /api/v1/servers/ and the server ID. Do not append that path a second time.
  3. Enter API Key. In Server ID, use the identifier exposed by your service, commonly localhost.
  4. Set Default Nameservers to the intended authoritative hostnames, separated by commas. They seed new zones; they do not create registry glue or change domain delegation.
  5. Save and check the connection, then assign it to a test package.

02 Check a complete lifecycle

The connection check authenticates to the server resource and can report its version. Follow that with an authorised zone read and a temporary record change. Read the zone back after the queued job finishes. For a newly provisioned primary zone, confirm the provider reports the intended primary/native role. For a secondary, verify its configured primary addresses instead of attempting ordinary primary-record edits.

DNSSEC requires working PowerDNS key operations and a separate parent DS update. Do not interpret the presence of a DNSSEC setting as proof that the chain validates publicly. If requests fail, compare the API origin, server ID, reverse-proxy routing and backend permissions. Preserve the provider error and task reference, and avoid creating a second copy of a zone merely because the first operation's response was uncertain.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support