Managing DNS at Scale with PowerDNS Operator

Benjamin Pinchon — Tue, 08 Jul 2025 17:10:00 +0000

Introducing PowerDNS Operator 🚀

PowerDNS Operator is a Kubernetes operator that bridges the gap between PowerDNS (a self-hosted, open-source DNS server) and cloud-native infrastructure. It allows you to manage DNS zones and records as Kubernetes Custom Resources, enabling declarative DNS management that fits perfectly into your existing GitOps workflows.

Github: https://github.com/powerdns-operator/PowerDNS-Operator

Key Features

Kubernetes-native - Manage DNS through Custom Resources
GitOps ready - Version control your DNS configuration
Multi-tenancy support - Namespace isolation for teams
Official API integration - Uses PowerDNS's API
Flexible deployment - PowerDNS can be inside or outside Kubernetes
Prometheus metrics - Built-in monitoring and observability
RBAC integration - Fine-grained permissions for different teams

Architecture Overview

The PowerDNS Operator introduces four Custom Resources that enable different levels of DNS management:

ClusterZone: Cluster-wide DNS zones
ClusterRRset: Cluster-wide DNS records
Zone: Namespace-scoped DNS zones
RRset: Namespace-scoped DNS records

This flexible architecture lets you structure DNS resources to match your organization's needs. For instance, platform teams can establish shared ClusterZones while developers self-manage their application DNS through namespace-scoped RRsets.

Quick Start

Prerequisites: Ensure you have a PowerDNS service operational and accessible from the PowerDNS Operator. The PowerDNS API must be enabled.

1. Install the Operator

# Add the Helm repository
helm repo add powerdns-operator https://powerdns-operator.github.io/PowerDNS-Operator-helm-chart
helm repo update

# Install the operator
helm install powerdns-operator powerdns-operator/powerdns-operator \
  --namespace powerdns-operator-system \
  --create-namespace \
  --set api.url=https://your-powerdns-server:8081 \
  --set credentials.data.PDNS_API_KEY=your-api-key

2. Create DNS Resources

ClusterZone (cluster-wide)

apiVersion: dns.cav.enablers.ob/v1alpha2
kind: ClusterZone
metadata:
  name: example.org
spec:
  kind: Native
  nameservers:
    - ns1.example.org
    - ns2.example.org

Zone (namespace-scoped)

apiVersion: dns.cav.enablers.ob/v1alpha2
kind: Zone
metadata:
  name: team-a.example.org
  namespace: team-a
spec:
  kind: Native
  nameservers:
    - ns1.example.org
    - ns2.example.org

RRset (namespace-scoped)

apiVersion: dns.cav.enablers.ob/v1alpha2
kind: RRset
metadata:
  name: api.team-a.example.org
  namespace: team-a
spec:
  type: A
  ttl: 300
  records:
    - 10.0.1.100
    - 10.0.1.101
  zoneRef:
    name: team-a.example.org
    kind: Zone

3. Verify and Test

# Check resources
kubectl get clusterzones,zones,rrsets -o wide -A


# Test DNS resolution
dig @your-resolver api.team-a.example.org +short

Operational Benefits

Team Separation

Platform team: Manages ClusterZones and infrastructure DNS
Development teams: Manage their own Zones and RRsets
RBAC controls: Granular permissions per namespace

GitOps Integration

Version control: All DNS configuration in Git
Automated deployments: DNS changes deploy alongside applications
Rollback capability: Easy to revert DNS changes

How do you manage the lifecycle of your DNS resources? Terraform, Ansible or... Jira?! Share your experiences in the comments below! 👇

DEV Community: Benjamin Pinchon