Introduction

If you want ExternalDNS to manage records for Services or Ingresses across the whole cluster, the important choice is scope. A cluster-scoped installation can watch supported resources in all namespaces, while a namespaced installation is intentionally limited and uses Role and RoleBinding objects instead of cluster-wide RBAC.

The main rule: use cluster scope for all namespaces

ExternalDNS documentation distinguishes between a normal cluster-scoped deployment and a namespaced-only deployment. If your goal is "all namespaces," do not enable namespaced scope. Keep the deployment cluster-scoped so the controller can watch resources across namespaces and use ClusterRole permissions.

That is the common setup for clusters where one ExternalDNS instance manages DNS for many teams or many applications.

In practice, that means:

• deploy one ExternalDNS controller in a chosen namespace, such as external-dns
• grant it cluster-wide read access to the Kubernetes resources it watches
• configure provider credentials once
• annotate Services or Ingresses in any namespace that should produce DNS records

Example Helm values for cluster-wide operation

A typical Helm configuration for a cluster-scoped installation looks like this:

1provider:
2  name: aws
3
4sources:
5  - service
6  - ingress
7
8policy: upsert-only
9registry: txt
10txtOwnerId: my-cluster-prod
11
12domainFilters:
13  - example.com
14
15serviceAccount:
16  create: true
17  name: external-dns
18
19namespaced: false

The critical detail is namespaced: false, or simply leaving namespaced mode disabled if that is already the chart default. That allows the chart to create ClusterRole and ClusterRoleBinding objects rather than namespace-limited Role objects.

Provider-specific settings still matter. For AWS Route 53, Cloudflare, Google Cloud DNS, and others, the controller also needs credentials with permission to edit the target zones.

What resources it watches across namespaces

ExternalDNS discovers DNS names from source resources such as:

• 'Service'
• 'Ingress'
• provider-specific or custom-resource sources, depending on configuration

With cluster-scoped RBAC, it can watch those supported resources in any namespace. Then you opt individual objects into DNS management using annotations such as the hostname annotation.

Example Service:

1apiVersion: v1
2kind: Service
3metadata:
4  name: api
5  namespace: payments
6  annotations:
7    external-dns.alpha.kubernetes.io/hostname: api.example.com
8spec:
9  type: LoadBalancer
10  selector:
11    app: api
12  ports:
13    - port: 80
14      targetPort: 8080

Example Ingress in a different namespace:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: web
5  namespace: storefront
6  annotations:
7    external-dns.alpha.kubernetes.io/hostname: shop.example.com
8spec:
9  ingressClassName: nginx
10  rules:
11    - host: shop.example.com
12      http:
13        paths:
14          - path: /
15            pathType: Prefix
16            backend:
17              service:
18                name: web
19                port:
20                  number: 80

One ExternalDNS deployment can reconcile both objects because the watch is cluster-wide.

When namespaced mode is the wrong choice

ExternalDNS also supports namespaced-only scope, but the documentation notes that not all sources are supported there. Cluster-scoped resources such as Node are not available in namespaced mode, and some source combinations only work if related resources live in the same namespace as the controller.

So if the question is specifically "how do I configure it in all namespaces," namespaced mode is usually the opposite of what you want. Namespaced mode is useful when a team is intentionally confining DNS automation to one namespace.

RBAC and filtering still matter

Cluster-wide visibility does not mean you must publish every record in the cluster. You can still constrain behavior with:

• 'domainFilters to limit which DNS zones are touched'
• annotation filters or label filters to limit which objects are considered
• source selection, such as watching only service and ingress
• a stable TXT owner identifier to avoid conflicts with other ExternalDNS instances

Those controls are important in shared clusters. They let you grant cluster-wide watch access while still narrowing the DNS records the controller may manage.

A practical deployment pattern

A common production setup is:

1. install ExternalDNS once in namespace external-dns
2. bind provider credentials only to that service account
3. enable cluster-scoped RBAC
4. restrict managed zones with domainFilters
5. let application teams annotate Services or Ingresses in their own namespaces

That gives teams self-service DNS without giving each namespace its own DNS controller and provider credentials.

Common Pitfalls

A common mistake is enabling namespaced scope and then expecting the controller to manage records for resources in every namespace. It will not.

Another mistake is giving ExternalDNS cluster-wide Kubernetes visibility but forgetting DNS provider permissions. Kubernetes RBAC alone does not let it edit Route 53, Cloudflare, or another external provider.

A third mistake is running multiple ExternalDNS instances against the same zones without separating ownership, filters, or TXT owner identifiers.

Summary

• To manage DNS records across all namespaces, install ExternalDNS in cluster scope.
• Do not enable namespaced-only mode for this use case.
• Use ClusterRole and ClusterRoleBinding permissions so the controller can watch supported resources cluster-wide.
• Keep control with domainFilters, source selection, and annotation-based opt-in.
• Use namespaced scope only when you intentionally want DNS automation limited to one namespace.