external-dns deletes DNS records when HTTPRoute transitions to Accepted=False (route still exists)

[sedflix]

What would you like to be added?

A flag (e.g., --gateway-route-require-accepted) to control whether external-dns checks the Accepted condition before producing endpoints from HTTPRoutes. When disabled, external-dns would use hostnames from the route spec regardless of acceptance status — only deleting DNS when the route object is actually removed.

Why is this needed?

When an HTTPRoute transitions from Accepted=True to Accepted=False (e.g., due to a bad config push), external-dns with --policy=sync deletes the DNS records — even though the route object still exists and the data plane may still be serving traffic.

gwRouteIsAccepted() in source/gateway.go returns false → zero endpoints → sync deletes the owned DNS records. This treats "temporarily invalid" the same as "intentionally removed."

Impact: A misconfiguration that would otherwise only affect routing now causes a full DNS outage. The only workaround is --policy=upsert-only, which disables all cleanup and requires manual orphan management.

Reproduction

1. Create a Gateway + HTTPRoute → Accepted=True → DNS records created
2. Push invalid change to HTTPRoute → Gateway sets Accepted=False
3. external-dns deletes DNS A + TXT records for that route

level=info msg="Del records: my-app.example.com. A [something] 300"
level=info msg="Del records: a-my-app.example.com. TXT [\"heritage=external-dns,...\"] 300"

Related issues

• Option to delete DNS records only if source is completely deleted #3841 — requested this, closed as Not Planned
• Don't destroy all DNS records when GKE Gateway is unhealthy because of one bad HTTPRoute #4595 / All records in GCP Cloud DNS removed on faulty HTTPRoute #4023 — cascading variant (one bad route affects all routes on a Gateway, different from this)

[ivankatliarchuk]

My overall take: this is worth closing, though I'd leave it open for a for community input.

The issue #4023, sounds like a bug, but not too sure.

--policy=sync is not a workaround - it is the correct behavior by design. The design principle is - sync engine (external-dns) reflects authoritative cluster state. You either trust full cycle or just partial.

External-dns is a sync engine, not a circuit breaker. It reflects what the cluster declares as valid at reconcile time. If a Gateway controller marks a route as Accepted=False, that is the cluster's authoritative signal. External-dns acting on it is correct. I'm not to sure what the right solution is, it could belong to admission layer or deployment process.

Adding this flag would likely make things worse, for example reasons:

• Scope creep / footgun risk - users disable the acceptance check, orphaned DNS records accumulate, and the failure mode becomes silent drift rather than a visible DNS gap.
• Process discipline - admission webhooks (Kyverno, OPA) are the solutions to prevent invalid config from reaching the cluster. That problem is not solvable inside external-dns, too many edge cases.
• Accepted=False on a still-existing route feels different from a deleted resource, but the semantics are the same: the cluster is declaring the route invalid. Treating them differently adds conceptual complexity.

One constructive path forward: a stabilization window in Gateway controllers before transitioning Accepted=False - giving the data plane time to recover from transient config errors without triggering downstream effects like DNS deletion.

That's an upstream ask. Worth filing a feature request in github as an issue and raising it in #sig-network-gateway-api on the Kubernetes Slack - that's where some Gateway API design discussions happen. We could act accordingly based on results of the issues opened.

[ivankatliarchuk]

Actually #4023 does not looks like a bug in external dns after reading comment #4023 (comment)

In regards #4595 is not relevant as a code issue in this repo today. The external-dns logic is per-route and correct.

There is no gateway-level health check anywhere in the code.

So the logic is:

• Route A bad → its own Accepted=False → Route A loses DNS ✓ (correct per design)
• Route B healthy → its own Accepted=True → Route B keeps DNS ✓ (correct)

In practice, it depends on the controller. The GKE-specific behavior reported in #4023 was that the GKE Gateway controller cascades a single bad route's failure and marks all routes under that gateway as Accepted=False. That's a GKE controller bug, not an external-dns bug. If GKE still does that, the symptom persists - but the fix belongs upstream in GKE's controller.

[ivankatliarchuk]

If you share your kubernetes resources chain, we may have a fallback already.

[sedflix]

Hey, thanks for the detailed response @ivankatliarchuk! I really appreciate you leaving this open for discussion.

I'm not 100% sure what the perfect solution is, but I believe Gateway API sources are fundamentally different from other sources(that I know if) in how they interact with external-dns.

For Ingress/Service/VirtualService, DNS deletion happens when IP data disappears or can't be inferred — most likely meaning the data plane is no longer serving traffic. With HTTPRoute, Accepted=False means something different: the new config is invalid and won't be applied, but the data plane may still be serving traffic using the previously applied configuration (e.g., Istio/Envoy's xDS NACK retains last-known-good config).

A deleted HTTPRoute deterministically says "remove this route." Accepted=False says "the new config is invalid" — while saying nothing about the previously applied configuration that may still be actively serving traffic. Deleting DNS while the data plane is still serving feels incorrect.

I'm not concerned about orphaned DNS records — deletion of the HTTPRoute object itself should handle that cleanup.

Unfortunately, I wasn't able to find a good ecosystem for validating webhooks for HTTPRoute. GKE, Istio, and Kong don't have complete semantic validation webhooks for it — Kong actually removed theirs because it caused more problems than it solved. Writing and maintaining rules for this in OPA/Kyverno seems impractical since you'd need to replicate each Gateway controller's validation logic.

I understand that bypassing the Accepted check introduces complexity in the Gateway source implementation. But I believe deleting DNS while the data plane is actively serving traffic is not the correct behavior — and the current ecosystem doesn't provide the admission-time safeguards needed to prevent this from happening.

[nico-stylemans]

In the following Case the dns records are also deleted

I have a configuration that depends on the envoyproxy object
I made a mistake in the logging configuraton with the CEL expression matching , the gateway object failed reporting error not a cel expression and all dns records are deleted.