feat(dns): PowerDNS Integration

[JustinBack]

Context

This PR adds PowerDNS Integration. I am not familiar with the code base so please bear with me :-)

Screenshots

Tested against Let's Encrypt Staging and PowerDNS Admin

Steps to verify the change

1. Add PowerDNS Connection
2. Add External CA
3. Add Certificate Profile
4. Add Certificate Policy
5. Request Certificate

Type

• Feature

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Read the contributing guide

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[greptile-apps]

Greptile Summary

This PR adds a PowerDNS integration as a new App Connection and DNS provider for ACME certificate issuance. The implementation follows the established patterns for other DNS providers (Cloudflare, DNS Made Easy, Azure DNS) and correctly addresses the SSRF and DNS propagation retry issues raised in previous review threads.

Key changes:

• New AppConnection.PowerDNS app connection with API key authentication and a user-supplied baseUrl
• blockLocalAndPrivateIpAddresses is called before every outbound request (in both the credential-validation path and the TXT record management functions), preventing SSRF
• encodeURIComponent is applied to zone names in URL paths, preventing path traversal
• powerDnsInsertTxtRecord uses changetype: "REPLACE" and powerDnsDeleteTxtRecord uses changetype: "DELETE", both consistent with the PowerDNS PATCH API
• The DNS propagation throw is correctly placed after the while loop (previous regression is fixed)
• Documentation bug: Both the .mdx doc (line 31) and the frontend tooltip (PowerDNSConnectionForm.tsx line 108) show http://your-powerdns-server:8081 as the direct-server base URL. Because the code appends /servers/localhost/zones, the actual PowerDNS API path /api/v1/servers/localhost/zones is never reached — users following the direct-server example will receive a 404. The examples should include /api/v1 (e.g. http://your-powerdns-server:8081/api/v1). The PowerDNS-Admin proxy example is correct.
• Minor: baseUrl with a trailing slash produces double-slash paths in all API calls (e.g. .../api/v1//servers/localhost/zones); consider normalizing with a .replace(/\/$/, "") before concatenation.

Confidence Score: 4/5

• Safe to merge after fixing the base URL examples in the documentation and tooltip — the logic bug only affects users who follow the direct-server example verbatim.
• A P1 documentation/tooltip inconsistency (missing /api/v1 in the direct PowerDNS base URL example) would cause a 404 for any user following the docs to connect a direct PowerDNS Authoritative Server. The PowerDNS Admin proxy path is correct and the author confirmed testing against PowerDNS Admin, so that path works. The code logic, security controls, and integration wiring are all sound.
• docs/integrations/app-connections/powerdns.mdx and frontend/.../PowerDNSConnectionForm.tsx need the direct-server base URL examples updated to include the /api/v1 prefix.

Important Files Changed

Filename	Overview
backend/src/services/app-connection/powerdns/powerdns-connection-fns.ts	Validates PowerDNS credentials by calling the zones endpoint; correctly calls blockLocalAndPrivateIpAddresses before the request to prevent SSRF, but URL concatenation can produce double-slash paths when baseUrl has a trailing slash.
backend/src/services/certificate-authority/acme/dns-providers/powerdns.ts	Implements TXT record insert and delete for PowerDNS ACME challenges; calls blockLocalAndPrivateIpAddresses before every request, uses encodeURIComponent on zone names preventing path traversal, and correctly uses changetype: "DELETE" to remove all TXT records for the given name.
backend/src/services/certificate-authority/acme/acme-certificate-authority-fns.ts	Adds PowerDNS to the ACME certificate ordering flow; DNS propagation retry logic is correct (throw is after the while loop), and all provider validation checks mirror the existing pattern.
backend/src/services/app-connection/powerdns/powerdns-connection-schema.ts	Schema definitions for PowerDNS connection; apiKey is correctly excluded from the sanitized schema, baseUrl is validated as a URL with length bounds, and the discriminated union structure matches the existing provider pattern.
docs/integrations/app-connections/powerdns.mdx	Documentation for PowerDNS connection setup; the direct server example URL (http://your-powerdns-server:8081) is missing the required /api/v1 path prefix, which would cause 404 errors for users following these instructions with a direct PowerDNS server.
frontend/src/pages/organization/AppConnections/AppConnectionsPage/components/AppConnectionForm/PowerDNSConnectionForm.tsx	PowerDNS connection form with API key and base URL fields; the tooltip example for direct server access is missing the /api/v1 path prefix, which could mislead users trying to connect directly to a PowerDNS server.
frontend/src/pages/cert-manager/CertificateAuthoritiesPage/components/ExternalCaModal.tsx	Added PowerDNS connection fetching and a manual zone name input for the PowerDNS ACME provider; integration follows the same pattern as the Route53 free-text zone ID.
backend/src/services/app-connection/powerdns/powerdns-connection-service.ts	Empty service factory — acceptable since PowerDNS only acts as a DNS provider for ACME challenges and needs no service-level operations (e.g., zone listing API) at this time.

_{Reviews (3): Last reviewed commit: "Remove duplicate delay call in waitForDn..." | Re-trigger Greptile}

[JustinBack]

Greptile Mitigations and Reviews have been applied :-)

[JustinBack]

It seems Infisical is checking too fast if DNS Records are propagated, I have increased the attempts to 30. With 2000ms delay we have a maximum of 120 Seconds, which is enough for most providers to propagate.

- const DNS_PROPAGATION_MAX_RETRIES = 5;
+ const DNS_PROPAGATION_MAX_RETRIES = 30;

I also added an Exception on DNS Check Fail as previously, even though the dns check exceeded the maximum attempts, did not stop the request from going to the ACME Server.

throw new Error(`DNS record "${lookupName}" with value "${expectedValue}" not found after ${DNS_PROPAGATION_MAX_RETRIES} attempts`);

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

[JustinBack]

Secret Detection was a false positive due to an accidental commit of the docker-compose.dev.yml, erased from the git history so the commit tree is clean.

[JustinBack]

@greptileai Rescan PR

[JustinBack]

The following tests have been done:

• Issue Cert with 1 CN
• Issue Cert with 1 CN and 3 SAN
• Issue Cert with 1 CN, 1 Wildcard and 2 SANs

DNS Propagation works perfectly fine now without Server Errors on ACME Side.

[JustinBack]

@greptileai