PowerDNS-AuthAdmin v1.9.1 documentation
Install, configure and run PowerDNS-AuthAdmin
Everything from a two-minute demo stack to a hardened production install: SQLite or Postgres, OIDC, SAML and LDAP sign-in, roles and scopes, one or many PowerDNS backends, and natural-language DNS over MCP.
Quick start
Getting started
Try it in two minutes, then install it for real and connect your PowerDNS servers.
- QuickstartTry the app end-to-end on a throwaway Docker stack with demo zones, in about two minutes.
- InstallationRun it for real: Docker or from source, SQLite or Postgres, a reverse proxy, backups and health checks.
- ConfigurationEvery environment variable, what it does and when you need it.
- PowerDNS backendsWire up standalone primaries, primary + secondaries groups and multi-primary clusters, plus DNSSEC and TSIG.
Sign-in & access
Single sign-on with OIDC, SAML or LDAP, passkeys, and the roles that decide who can do what.
- OIDC single sign-onSet up SSO with any OpenID Connect provider and map IdP groups to roles.
- SAML 2.0 single sign-onSet up SAML SSO with AD FS, Authentik or Keycloak.
- LDAP sign-inAuthenticate directly against Active Directory or OpenLDAP.
- Passkeys & security keysUse WebAuthn as passwordless sign-in or as a second factor.
- Roles & permissionsThe five system roles, the permission vocabulary, scopes, custom roles and MFA-required roles.
Operations
Provision a whole install from YAML, lock it down, upgrade it and fix it when something breaks.
- First-boot provisioningBring up a fully configured install from one YAML file, and how to re-apply it.
- HardeningLock down a production deployment: secrets, network exposure, authentication, least privilege and image signatures.
- UpgradingMove to a new version safely, with the notes that apply to each release.
- TroubleshootingFix a startup error, a backend that won't connect, a sign-in that does nothing or a lost admin account.
Integrations & reference
Talk to your DNS from an AI assistant, browse the full feature catalog, or set up a dev environment.
Architecture decisions
Why the codebase is shaped the way it is: one short record per load-bearing decision.
- 0001Choose Next.js 15 + React Server Components as the frameworkAccepted
- 0002License under MITAccepted
- 0004Three-layer architecture (auth → RBAC → business logic)Accepted
- 0005Migrations are never auto-applied on app bootSuperseded by 0011
- 0006Per-request CSP nonceAccepted
- 0007DB-backed sessions over stateless JWTsAccepted
- 0008Argon2id for password hashingAccepted
- 0009Roll our own auth core on openid-client + argon2, not Auth.jsAccepted
- 0010Per-RRset optimistic concurrency for the editorAccepted
- 0011Migrations run at app-container bootAccepted, supersedes 0005
- 0012First-boot provisioning + OIDC group → role materialisationAccepted
- 0013The PDNS client's sanctioned DB bridge (and fixing boundary enforcement)Accepted
- 0014Per-zone authority + observed daemon capabilities (retire per-server role)Accepted
- 0015Backend health advisories (the notification bell)Accepted
- 0016Optional Redis for horizontal scale (replicas > 1)Accepted
- 0017Squash the 1.1.0 schema deltas into one migration per dialectAccepted
- 0018Multi-provider auth: keep OIDC where it is, layer SAML + LDAP as siblingsAccepted
- 0019WebAuthn: both primary credential and second factorAccepted
- 0020LDAP authentication architectureAccepted
- 0021SAML 2.0 service-provider architectureAccepted
- 0022Zone horizons: app-side split-horizon classificationAccepted
- 0023Zone authority is a separate permission from zone recordsAccepted