Ability to use specific annotations with specific edns instance

[lexfrei]

What would you like to be added:
An option to mark annotations to be used with specific instance of edns.

Why is this needed:
In some cases, we need to use not just multiple providers, but different targets in each.
For example, I wanna create public dns and private dns for the same ingress to simplify routing.
Currently, I have these annotations:

    external-dns.alpha.kubernetes.io/target: "uuid.cfargotunnel.com"
    external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"

but in the future I wanna use it like this:

    external-dns.alpha.kubernetes.io/target-cf: "uuid.cfargotunnel.com"
    external-dns.alpha.kubernetes.io/cloudflare-proxied-cf: "true"

    # or completely remove this to use ip from ingress status
    external-dns.alpha.kubernetes.io/target-local: "10.0.66.6"

Not just postfix can be used. The domain customization or prefix is fine too.

This looks very useful for multi instance usage of edns

[ivankatliarchuk]

You may need to share a bit more details to capture the idea. So you have different instances running one for each provider, what is the setup, which sources do you use, annotation examples?

Do you mind to create a guide for multi instance setup https://github.com/kubernetes-sigs/external-dns/tree/master/docs/tutorials?

[lexfrei]

@ivankatliarchuk, thanks for your feedback. I’d like to provide some additional context to clarify my proposal further.

Right now, I’m not running two separate external-dns deployments—even though I’d like to—because I don’t have a way to differentiate the annotations. The inability to parse custom, provider-specific annotations is a significant blocker for me.

My Current Situation:
• Single Deployment Limitation:
I currently run a single deployment since there’s no mechanism to assign different targets based on provider-specific annotations.
• Desired Setup:
Ideally, I’d like to run separate deployments for each provider (one for Cloudflare and one for Unifi). This way, each deployment would only process the annotations relevant to its provider. For example, I propose using a naming scheme that prepends the provider to the annotation key, such as:
• cf.external-dns.alpha.kubernetes.io/target for Cloudflare
• unifi.external-dns.alpha.kubernetes.io/target for Unifi

Why This Matters:

In my environment, Traefik is used to manage various endpoints based on specific routing rules. This approach lets me avoid the traditional method of running separate nginx-ingress instances for every case. I have endpoints that serve internal network requests (for Unifi) and an endpoint that manages a Cloudflare tunnel. With the proposed annotation mechanism, I could simply annotate my Ingress resources to automatically create both DNS records—one for the internal office and one for public access—without conflicting configurations.

I hope this additional detail clarifies my proposal. The current inability to parse custom annotations for different deployments is a blocker for me, and addressing it would greatly improve flexibility in multi-provider environments.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lexfrei]

/remove-lifecycle stale

[allancassaro]

I would like to add my 2 cents on this.
Our company uses 2 different DNS providers as well, Cloudflare and GCP CloudDNS.

I would like to suggest to have something close to how External Secret Operator does. For every secret, we have to add a SecretStore field. Like this example (CRD):

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: vault-example
spec:
  refreshInterval: "15s"
  secretStoreRef:               <<< Here is the SecretStore section
    name: vault-backend
    kind: SecretStore
  target:
    name: example-sync
  data:
    - secretKey: foobar
      remoteRef:
        key: kv/demo
        property: name

With this, it is possible to specify from where we want to pull a secret. We can configure multiple SecretStore and pull or push secrets from or to multiple places.

My suggestion on this would be to have a similar way to create multiple DNS Providers and using an annotation or a CRD we could specify which provider we would like to use for that particular record.

Using the original example, my suggestion would be to implement something like:

external-dns.alpha.kubernetes.io/target: "uuid.cfargotunnel.com"
external-dns.alpha.kubernetes.io/provider: cloudflare-provider-account1
external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"

Using the the /provider annotation, we could create multiple providers and the annotation would target that particular provider.

Update
This is an example on how we could do using the CRD:

---
apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSEndpoint
metadata:
  name: targets
  namespace: default
spec:
dnsProviderRef:
  name: cloudflare-provider-account1
  endpoints:
  - dnsName: smoke-t.example.com
    recordTTL: 300
    recordType: CNAME

And we could and a DNS Provider CRD:

apiVersion: externaldns.k8s.io/v1alpha1
kind: DNSProvider
metadata:
  name: cloudflare-provider-account1
  namespace: default
spec:
  env:
    - name: CF_API_TOKEN
      valueFrom:
        secretKeyRef:
          name: cloudflare-api-key
          key: apiKey
  source: ingress
  provider: cloudflare
  domains:
    - domain.tld
    - some.other.domain.tld

Thank you very much for your great work on this tool.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[lexfrei]

/remove-lifecycle stale
#5889

[kashalls]

I already commented on the Pull Request, but I think this PR would help fix some of the problems users have when running two custom webhook providers as split dns providers. All of the webhook providers share a external-dns.alpha.kubernetes.io/webhook-* key, but with this they no longer need to share it.

Thanks for your work on this @lexfrei !