corenetworks-dns-operator

#

Manages DNS records at Core Networks from DNSRecord objects in this cluster.

Chart and source: pyrox/corenetworks-dns-operator

Contents

#

No rendered manifests here. The CRDs, RBAC and Deployment come from the chart, which generates the CRD schema from the operator’s Go types — so this cluster cannot end up with a schema that does not match the controller it runs.

A second cluster

#

Copy this directory, change values.yaml, keep the chart version identical. That version is the only thing the two clusters have to agree on; Renovate raises it in both when a new chart is published.

Credentials

#

values.yaml points the zone at the core-networks-api Secret in the cert-manager namespace, where it was first stored for an ACME DNS-01 solver that never went live. Nothing new to store, one place to rotate.

rbac.secretNamespaces is set to that one namespace, so the operator gets a Role in cert-manager instead of cluster-wide read access to every Secret. Moving the credentials elsewhere means adding that namespace here too.

Adding a record

#

Records belong with the workload that needs them, not in this directory:

 1apiVersion: dns.zyria.de/v1alpha1
 2kind: DNSRecord
 3metadata:
 4  name: whoami
 5  namespace: whoami
 6spec:
 7  zoneRef: zyria-de
 8  name: whoami
 9  type: A
10  values:
11    - 192.0.2.1

kubectl get dnsrecords -A shows two columns worth reading: READY means the provider database matches the object, PUBLISHED means the zone has been committed so the nameservers actually answer with it.

ACME webhook

#

webhook.enabled deploys the chart’s cert-manager DNS-01 solver next to the operator. A ClusterIssuer refers to it with groupName: acme.dns.zyria.de and solverName: corenetworks; for each challenge the webhook creates a TXT DNSRecord in this namespace and the operator publishes it. The webhook holds no Core Networks credentials.

A ValidatingAdmissionPolicy holds every DNSRecord created or changed in this namespace to TXT under _acme-challenge with exclusive: false. Records for workloads belong in their own namespaces anyway; here they would be refused.

The webhook runs behind an APIService. If no replica is ready, API discovery reports errors for every client and namespace deletion can hang; check kubectl get apiservice v1alpha1.acme.dns.zyria.de first when that happens.

The ClusterIssuer corenetworks in apps/cert-manager uses it. Passed a staging test with an apex and a wildcard name on 2026-10-17: both challenges were solved one after the other within about three minutes, and the TXT values were gone from the provider afterwards.

Watch out

#

• Records this operator owns must not also be written by the core_networks_dns Ansible role or by hand in the provider web interface. They do not coordinate, and each would undo the other on its next run.
• Deleting the DNSZone is held back while DNSRecord objects reference it — delete the records first, otherwise their cleanup loses the credentials it needs. The zone also carries helm.sh/resource-policy: keep, so uninstalling the release does not take it along.
• The Deployment uses strategy: Recreate on purpose. The pending commits live in the process, and a second replica would publish the same zone twice.