Closed interone-ms closed 6 months ago
That annotation is not documented to do what you are expecting it to do.
Apologies for piggybacking on this issue .. there seems to be an old closed issue around this as well ..
https://github.com/kubernetes-sigs/external-dns/issues/3128
It feels like the OP is trying to basically solve the same issue with this annotation ..
is there any way to influence which zone the controller will chose to add records to in the event of overlapping zone names at all?
I'd really take any of the following:
According to the code, the AWS provider will apply changes to the public zone with the longest domain, if any, plus all matching private zones. This is not configurable other than by excluding zones outright.
Hi, Today I faced this issue. I have scenario when records destination hostedzone must be explicitly specified (private, public or both). I wanted to solve it using Ingress annotation but probably I will end up with three external-dns helm releases.
I've just ran into this issue as well, in our case we have a split-dns setup with private and public hosted zones for the same domain name, and I've tried to separate these with the annotation.
@piotrb: I'd prefer specifying the exact zone ID to use, much as if the entire deployment was scoped to this specific zone id. This might even be possible to implement in a provider-agnostic manner.
If such a solution is a viable way forward, i'd be willing to contribute a PR for it.
@martin31821 given your use case, yep .. you definitely can only use the zone id .. my options were a bit more aligned with ease of use :) I wouldn't want expect my fellow developers to be specifying zone id's in specs unless the usecase absolutely required it (eg. yours)
It's the same case for us, not to mention that having the same record in multiple zones can be confusing and is, frankly, a pollution for the top-level domain's zone file.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
What happened: When using the
external-dns.alpha.kubernetes.io/aws-target-hosted-zone
annotation in an environment with multiple overlapping zones,external-dns
tries to create records in zones other than the one specified in the annotation.What you expected to happen:
external-dns
should only attempt to create records in specified zones.How to reproduce it (as minimally and precisely as possible):
be.foo.example.com
Anything else we need to know?:
Environment:
external-dns --version
): 0.13.4