v0.2.0

Production hardening. No API, controller or rendering change: what ZoneRoute
does is byte-for-byte what v0.1.0 did, and an upgrade is an in-place
kubectl apply over the previous version. What changed is how much of that
behaviour is proven before a release goes out.

Verified before a release

• The upgrade path itself. A lane installs the exact v0.1.0 release —
  fetched by its published checksum, running the digest-pinned image it
  ships — creates a route, proves DNS resolves, then applies the working tree
  over it. The ZoneRoute and the CRD keep their UIDs, the spec and generation
  are unchanged, conditions reconverge, the fragment is identical byte for
  byte, and the same route still resolves. No deletion, no migration, no
  manual step.
• Two Kubernetes versions. The supported floor, 1.31, remains the
  authoritative target on every pull request. A second lane runs the CRD
  checks, the install bundle and the functional suite against a newer pinned
  release weekly. 1.31 is still the minimum; the newer lane demonstrates
  forward compatibility rather than widening what is supported.
• Multi-replica CoreDNS. The default two-replica layout is back in the
  required pull-request path: each replica reloads on its own schedule, and a
  fragment that reaches only one of them now fails the suite.
• Transient Kubernetes API failures. A failing list, a failing ConfigMap
  read and a lost optimistic-concurrency race on the status subresource are
  each returned rather than swallowed, publish nothing they did not achieve,
  and converge on the next reconcile.

Project

• Dependency updates for the Go module graph, the workflow actions and the
  container base images, weekly and bounded. The Kubernetes test images and
  the kind versions stay manual: which versions ZoneRoute supports is a
  decision, not an update.
• Issue forms for bug reports and for CoreDNS integration problems, asking
  for the evidence a report needs and drawing an explicit line around what
  must never be pasted into a public tracker.
• A project site at zoneroute.mihnk.org,
  rendering the same Markdown that lives in this repository.

Baseline

Unchanged from v0.1.0: Kubernetes 1.31 or newer, CoreDNS 1.7.0 or newer with
the reload plugin.

Known limitations

Unchanged from v0.1.0 — nothing in this release altered the integration
contract or the API:

• CoreDNS only; there is no integration with any other DNS server.
• Kubernetes 1.31 and CoreDNS 1.7.0 are hard minimums.
• The standard CoreDNS listener on port 53 is assumed; a CoreDNS started with
  a non-default -dns.port is outside the integration contract.
• Upstreams are IP addresses only — hostnames are rejected.
• Upstreams are tried sequentially, in the order given; there is no other
  policy.
• Reverse zones are not managed: in-addr.arpa and ip6.arpa are rejected.
• The controller does not verify that CoreDNS reloaded the fragment, that the
  mount is healthy, or that an upstream resolver is reachable. Published
  reports what was written, not what resolves.
• The controller does not create kube-system/coredns-custom and does not
  wire CoreDNS; both remain installation steps.

Upgrading from v0.1.0

Apply the new release over the old one. The CRD is unchanged, existing
ZoneRoutes are untouched, and coredns-custom keeps its keys:

kubectl apply -f https://github.com/mihnk/zoneroute/releases/download/v0.2.0/install.yaml

Documentation

Installation ·
CoreDNS wiring ·
Troubleshooting

Install

kubectl apply -f https://github.com/mihnk/zoneroute/releases/download/v0.2.0/install.yaml

The manifest installs the CRD, the zoneroute-system namespace, RBAC and the
controller. It does not create kube-system/coredns-custom and does not
touch CoreDNS; establish the integration contract once, as described in
docs/coredns-wiring.md.

Image

ghcr.io/mihnk/zoneroute:v0.2.0
ghcr.io/mihnk/zoneroute@sha256:e291817252e11c3ea3d43449c1dacec4044ee232d6a3c876695471289d7bd8f7

Platforms: linux/amd64, linux/arm64. The installation manifest above pins the
digest, not the tag. Build provenance and an SBOM are attached to the image;
verify the provenance with:

gh attestation verify oci://ghcr.io/mihnk/zoneroute@sha256:e291817252e11c3ea3d43449c1dacec4044ee232d6a3c876695471289d7bd8f7 --repo mihnk/zoneroute

v0.1.0

First public release.

ZoneRoute forwards DNS zones to upstream resolvers on a Kubernetes cluster
that uses CoreDNS. A ZoneRoute names the zones and an ordered list of
upstream IP addresses; the controller renders a CoreDNS configuration
fragment for every accepted route and publishes it into a single key of a
single ConfigMap, kube-system/coredns-custom → zoneroute.server. It never
edits the Corefile or the CoreDNS Deployment: CoreDNS picks the fragment up
through a one-time import custom/*.server wiring the administrator
establishes.

Baseline

• Kubernetes 1.31 or newer — the CRD validates upstream addresses with the
  CEL IP library.
• CoreDNS 1.7.0 or newer with the reload plugin — from 1.7.0 the plugin
  detects changes in imported files.

What it does

• ZoneRoute (dns.mihnk.org/v1alpha1, cluster-scoped): zones plus an
  ordered list of upstream resolvers, validated by the API server.
• Two status conditions, Accepted and Published, each with a reason and a
  message that names the zones, routes or files involved.
• Conflict resolution against other ZoneRoutes and against the zones CoreDNS
  already serves, whether they come from the Corefile or from another
  *.server key.
• Reserved-zone protection for the cluster domain, so a route can never
  capture service discovery.
• A deterministic fragment: the same routes always render the same bytes.
• Minimal RBAC — the controller may patch exactly one ConfigMap and may not
  create ConfigMaps at all.

Validation

The kind and kubeadm CoreDNS layout is validated by a functional suite that
runs against real CoreDNS on every pull request. AKS and Gardener are
design-compatible but not validated by this project; EKS with the managed
add-on is unverified; GKE with kube-dns is not supported. See
docs/coredns-wiring.md.

Known limitations

• CoreDNS only; there is no integration with any other DNS server.
• Kubernetes 1.31 and CoreDNS 1.7.0 are hard minimums.
• The standard CoreDNS listener on port 53 is assumed; a CoreDNS started with
  a non-default -dns.port is outside the integration contract.
• Upstreams are IP addresses only — hostnames are rejected.
• Upstreams are tried sequentially, in the order given; there is no other
  policy.
• Reverse zones are not managed: in-addr.arpa and ip6.arpa are rejected.
• The controller does not verify that CoreDNS reloaded the fragment, that the
  mount is healthy, or that an upstream resolver is reachable. Published
  reports what was written, not what resolves.
• The controller does not create kube-system/coredns-custom and does not
  wire CoreDNS; both remain installation steps.

Documentation

Installation ·
CoreDNS wiring ·
Troubleshooting

Install

kubectl apply -f https://github.com/mihnk/zoneroute/releases/download/v0.1.0/install.yaml

The manifest installs the CRD, the zoneroute-system namespace, RBAC and the
controller. It does not create kube-system/coredns-custom and does not
touch CoreDNS; establish the integration contract once, as described in
docs/coredns-wiring.md.

Image

ghcr.io/mihnk/zoneroute:v0.1.0
ghcr.io/mihnk/zoneroute@sha256:01d5a9c73ff82111ee3b70b419cf5600bf54004de05718afcafddc0775e7b6c3

Platforms: linux/amd64, linux/arm64. The installation manifest above pins the
digest, not the tag. Build provenance and an SBOM are attached to the image;
verify the provenance with:

gh attestation verify oci://ghcr.io/mihnk/zoneroute@sha256:01d5a9c73ff82111ee3b70b419cf5600bf54004de05718afcafddc0775e7b6c3 --repo mihnk/zoneroute