Yes, but with caution. The operator only supports the official PowerDNS API, while PowerDNS-Admin implements its own custom API. Both can coexist, but avoid managing the same resources with both tools to prevent conflicts.
No. The operator is designed to manage a single PowerDNS server. For multiple servers, deploy separate operator instances in different clusters.
No. The operator only reconciles on Kubernetes events (create, update, delete). It does not periodically check for drift between Kubernetes resources and PowerDNS. This feature may be added in future versions.
The operator will delete the zone from PowerDNS, which removes all records in that zone. Additionally, due to Kubernetes owner references, all RRSets and ClusterRRSets that reference the deleted zone will be automatically deleted from Kubernetes as well. This cascading deletion ensures that orphaned records don't remain in the cluster.
No. The operator only works with PowerDNS Authoritative Server. The Recursor does not have the same API for zone and record management.
The operator manages the PowerDNS server configuration but does not control DNS propagation. Consider TTL values and upstream DNS server configurations for propagation timing.
Check for:
- Duplicate zones with the same FQDN
- PowerDNS API connectivity issues
- Invalid zone configuration (nameservers, etc.)
- PowerDNS Operator logs
Check for:
- Referenced zone exists and is healthy
- No duplicate records with the same name and type
- PowerDNS API permissions
- Record format (especially for CNAME, MX, SRV records)
- PowerDNS Operator logs