You retire an ingress controller (the component that routes outside traffic into the cluster) and release its address. Three DNS records still point at that address, so they are proxied and return errors. Nobody notices until someone sweeps every zone by hand. Now put DNS in git and add an agent that checks every record against what actually runs. Then those records become a draft merge request (MR) next to the retirement. The design of this lane is written, and a first read-only check of the records is in development. The read-only Cloudflare access that it builds on is live.
A migration wave moves the last routes from the old controller to the new one. Then your team removes the old controller, and its static load-balancer address goes 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 that the records exist.
Without this lane, people find these records in a one-off sweep. They check every account and every zone. Then they match hundreds of records by hand against the addresses that they release.
You import every account and zone from Cloudflare, so nobody writes them by hand. The repository records which objects it declares and which objects it only observed. Merge requests show a plan, and the main branch applies it.
The write token lives only in CI. The assistant keeps its read-only Cloudflare tokens, the same tokens that its Cloudflare posture review already uses in production.
A rule-based agent does this join, with no AI model (LLM) involved. It compares the records in the repository and the live records with two things. The first is the hosts that live Ingress, IngressRoute and HTTPRoute objects declare. The second is the LoadBalancer addresses on each cluster.
It only looks at A, AAAA and
CNAME records. Otherwise a verification
TXT record on the same name would mask the address
record and produce false findings.
Each account or zone has an explicit management mode. Managed: the DNS repository is authoritative for what it declares. CI holds a write token. The assistant proposes draft MRs. Advisory: you manage the zone yourself. The assistant only reads it and opens issues.
The mode decides whether the assistant opens an MR or an issue. The mere presence of a token never decides it.
Proxy, page-rule and Access settings can live in the repository, but not exclusively. The assistant reports an object that the repository does not declare as drift to review. It never proposes to delete that object, and the apply never purges it.
A dashboard edit to a declared record is real drift. The assistant opens 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 compares the retired address with the records. The MR then cites the records that the retirement would leave dangling, with a link to the matching DNS MR. So the cleanup is part of the change, not a sweep months later.
The diff removes three records from the DNS repository. The MR body shows why each record is dangling. It shows 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 }
This MR is illustrative and on the roadmap. The record format is neutral on purpose. The design uses one record format for every DNS provider, with Cloudflare first.
gitops-ai/dns-dangling-acme-example into main · 1 file · +0 −3Three proxied A records in acme.example point at 203.0.113.10. This is the load-balancer address of the legacy ingress controller that the companion MR retires. No live load balancer holds that address. No route declares these hosts. Visitors currently get an error page.
No live route on any cluster declares any of the three hosts. So there is no correct target to repoint to. If one of them must stay, repoint it to 203.0.113.20 and add a route for it instead.
acme.example is managed: the repository is authoritative for the records it declares. The MR changes only these three declared records. It purges nothing undeclared.
| 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 |
The assistant joined only A, AAAA and CNAME records. It read the routes and addresses of every cluster completely. A partial read would have produced an issue instead of this MR.
acme.example, no creations and no modifications.dig login.acme.example returns NXDOMAIN.Revert this MR. CI then 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 no route declares the three hosts. The diff touches only declared records. LGTM.
DNS mistakes become public within minutes. The design relies on read-only access and explicit ownership.
TXT and other record types that share a name. Those records caused false findings in the manual sweeps.