You retire an ingress controller and release its address. Three DNS records still point at it, proxied, returning errors, and nobody notices until someone sweeps every zone by hand. With DNS in git and an agent that checks every record against what actually runs, those records become a draft MR next to the retirement. This lane is designed; the read-only Cloudflare access it builds on is live.
A migration wave moves the last routes from the old controller to the new one. The old controller is removed, and its static load-balancer address is released back to the cloud provider.
The Kubernetes side is clean. DNS lives somewhere else.
The records are proxied, so Cloudflare keeps answering for them and returns errors to visitors. Nothing in the cluster knows they exist.
The way this is found today is a one-off sweep: every account, every zone, hundreds of records, joined by hand against the addresses that are being released.
Every account and zone is imported from Cloudflare, never hand-written, recording which objects the repo declares and which it only observed. Merge requests show a plan; main applies it.
The write token lives only in CI. The assistant keeps its read-only Cloudflare tokens, the same ones its Cloudflare posture review already uses in production.
A deterministic agent, with no LLM in the loop, joins repo records and live records against the hosts declared by live Ingress, IngressRoute and HTTPRoute objects, and against the LoadBalancer addresses on each cluster.
It only looks at A, AAAA and
CNAME records. A verification TXT record
on the same name would otherwise mask the address record and
produce false findings.
Each account or zone has an explicit management mode. Managed: the DNS repo is authoritative for what it declares, CI holds a write token, and the assistant proposes draft MRs. Advisory: you manage the zone yourself; the assistant only reads it and files issues.
The emission surface follows the mode, never the mere presence of a token.
Proxy, page-rule and Access settings can live in the repo, but not exclusively. An object the repo does not declare is reported as drift to review, never proposed for deletion, and the apply never purges it.
A dashboard edit to a declared record is real drift: an MR to accept the live value, or an issue to discuss it.
When an MR retires a host or a load balancer, the DNS lane joins the retired address against the records and cites the ones that would be left dangling, with a link to the matching DNS MR. The cleanup is part of the change, not a sweep months later.
The diff removes three records from the DNS repo. The MR body shows why each one is dangling, what the CI plan will do, and what to check after the apply. The full MR is below.
- infrastructure/ingress-legacy/helmrelease.yaml - infrastructure/ingress-legacy/service.yaml loadBalancerIP: 203.0.113.10 # released
| name | type | content | proxied |
|---|---|---|---|
| shop | A | 203.0.113.20 | yes |
| login | A | 203.0.113.10 | yes |
| api | A | 203.0.113.20 | yes |
| preview | A | 203.0.113.10 | yes |
| grafana-old | A | 203.0.113.10 | yes |
| www | CNAME | shop.acme.example | yes |
zone: acme.example mode: managed records: - { name: shop, type: A, content: 203.0.113.20, proxied: true } - { name: login, type: A, content: 203.0.113.10, proxied: true } - { name: www, type: CNAME, content: shop.acme.example } observed_only: - page rule "legacy-redirect" # not declared, never purged
✓ shop.acme.example → 203.0.113.20 → route shop/storefront ✕ login.acme.example → 203.0.113.10 → no load balancer · _verify.shop TXT ignored: not an address record
- - { name: login, type: A, content: 203.0.113.10, proxied: true } - - { name: preview, type: A, content: 203.0.113.10, proxied: true } - - { name: grafana-old, type: A, content: 203.0.113.10, proxied: true }
Illustrative and on the roadmap. The record format is neutral on purpose: which DNS-as-code tool to use is still an open decision.
gitops-ai/dns-dangling-acme-example into main · 1 file · +0 −3Three proxied A records in acme.example point at 203.0.113.10, the load-balancer address of the legacy ingress controller retired in the companion MR. No live load balancer holds that address and no route declares these hosts. Visitors currently get an error page.
None of the three hosts is declared by any live route on any cluster, so there is no correct target to repoint to. If one of them should stay, repoint it to 203.0.113.20 and add a route for it instead.
acme.example is managed: the repo is authoritative for the records it declares. Only these three declared records are touched; nothing undeclared is purged.
| Record | Points at | Load balancer | Route declaring the host |
|---|---|---|---|
| login | 203.0.113.10 | none (released) | none on any cluster |
| preview | 203.0.113.10 | none (released) | none on any cluster |
| grafana-old | 203.0.113.10 | none (released) | none on any cluster |
Only A, AAAA and CNAME records were joined. Every cluster's routes and addresses were read completely; a partial read would have produced an issue instead of this MR.
acme.example, no creations, no modifications.dig login.acme.example returns NXDOMAIN.Revert this MR; CI recreates the three records as they were.
records:
- { name: shop, type: A, content: 203.0.113.20, proxied: true }
- - { name: login, type: A, content: 203.0.113.10, proxied: true }
- { name: api, type: A, content: 203.0.113.20, proxied: true }
- - { name: preview, type: A, content: 203.0.113.10, proxied: true }
- - { name: grafana-old, type: A, content: 203.0.113.10, proxied: true }
- { name: www, type: CNAME, content: shop.acme.example }
Confirmed the address is no longer allocated and that no route declares the three hosts. Diff touches only declared records. LGTM.
DNS mistakes are public within minutes. The design leans on read-only access and explicit ownership.
TXT and other record types that share a name, a bug class that produced false findings in the manual sweeps.