Summary
It would be useful to explore the ability to configure a secondary IP address on the CoreDNS deployments managed by the operator.
Motivation
In some cluster setups, CoreDNS benefits from being reachable on multiple IPs — for example, to support a dedicated in-cluster DNS VIP alongside the standard kube-dns ClusterIP. Having the operator manage this would keep the configuration DRY and in sync with the NextDNS profile lifecycle.
Proposal
Explore surfacing a configuration option (e.g. in the operator's CRD or Helm values) that allows users to specify one or more additional IPs to bind to the CoreDNS deployment — whether via an additional Service, a LoadBalancer IP, or another mechanism appropriate for the operator's architecture.
Questions to consider
- Should the secondary IP be expressed as an additional
Service of type LoadBalancer or ClusterIP?
- Should it be tied to the profile CRD, or a top-level operator config?
- Are there any conflicts with how CoreDNS itself binds to interfaces?
Happy to provide more context on the use case if helpful.
Summary
It would be useful to explore the ability to configure a secondary IP address on the CoreDNS deployments managed by the operator.
Motivation
In some cluster setups, CoreDNS benefits from being reachable on multiple IPs — for example, to support a dedicated in-cluster DNS VIP alongside the standard
kube-dnsClusterIP. Having the operator manage this would keep the configuration DRY and in sync with the NextDNS profile lifecycle.Proposal
Explore surfacing a configuration option (e.g. in the operator's CRD or Helm values) that allows users to specify one or more additional IPs to bind to the CoreDNS deployment — whether via an additional
Service, aLoadBalancerIP, or another mechanism appropriate for the operator's architecture.Questions to consider
Serviceof typeLoadBalancerorClusterIP?Happy to provide more context on the use case if helpful.