Rancher Global DNS: Automated Multi-Cluster DNS (2026)

Rancher Global DNS doesn’t actually manage DNS records; it orchestrates the deployment of DNS controllers that do manage DNS.

Let’s see it in action. Imagine you have two Kubernetes clusters, cluster-a and cluster-b, both managed by Rancher. You want to expose a service running on cluster-a so it’s accessible via a DNS name that resolves correctly regardless of which cluster a user might be connected to.

First, you’d install the Global DNS controller in Rancher. This isn’t a single monolithic deployment; it’s typically a set of Custom Resource Definitions (CRDs) and a controller that watches them.

# Example Global DNS CRD
apiVersion: management.cattle.io/v3
kind: GlobalDNSRecord
metadata:
  name: my-app-service
  namespace: default
spec:
  projectDomainName: my-app.example.com
  dnsProviders:
    - name: aws-route53
      aws:
        region: us-east-1
        zoneType: public
  multicluster:
    enabled: true
    # This field is crucial: it tells the controller to look for
    # matching services across multiple clusters.
    clusters:
      - clusterId: c-abcde:p-fghij
        serviceName: my-app-service
        serviceNamespace: default
      - clusterId: c-klmno:p-qrstu
        serviceName: my-app-service
        serviceNamespace: default

When you apply this GlobalDNSRecord custom resource, the Global DNS controller does a few things:

1. Identifies DNS Provider: It sees aws-route53 and knows it needs to interact with AWS Route 53.
2. Locates Target Services: It scans the specified clusters (c-abcde and c-klmno) for services named my-app-service in the default namespace.
3. Gathers Endpoints: For each matching service, it retrieves the cluster’s ingress endpoints or NodePort IPs and ports.
4. Creates DNS Records: It then configures Route 53 to create A or CNAME records for my-app.example.com that point to the ingress endpoints of my-app-service in both cluster-a and cluster-b. If you’ve configured health checks, Route 53 will intelligently route traffic to the healthy endpoint.

The magic here is that you define one desired DNS name (my-app.example.com) and associate it with services across multiple clusters. Rancher’s Global DNS controller then automates the creation and maintenance of the actual DNS records in your chosen provider (like Route 53, Cloudflare, or Azure DNS).

This solves the problem of managing DNS entries manually for services that need to be highly available or accessible across distributed Kubernetes environments. Instead of updating DNS records every time a service is deployed or scaled in a new cluster, you simply update the GlobalDNSRecord CR.

The multicluster.clusters field is where the orchestration happens. You list the Rancher cluster IDs and the specific service names and namespaces within those clusters. The controller uses this information to query the Kubernetes API of each cluster, retrieve the relevant endpoints, and then translate those into DNS records.

When a service is updated, scaled, or removed in one of the listed clusters, the Global DNS controller detects the change (via Kubernetes API watches) and automatically updates the corresponding DNS records in your provider. This ensures that my-app.example.com always resolves to a live, healthy instance of your application.

The projectDomainName is the publicly resolvable DNS name you want to expose. The dnsProviders section specifies how and where these records will be managed. You can have multiple providers listed, and the controller will attempt to manage the records across all of them.

A common point of confusion is that Global DNS doesn’t create the ingress or expose the service itself. It relies on your underlying Kubernetes cluster’s ingress controllers or load balancers to actually make the service accessible externally. Global DNS then points to those external endpoints. The health checking capabilities of your DNS provider are crucial for ensuring that traffic is routed away from unhealthy instances.

The multicluster.clusters field can also accept a clusterGroup ID, allowing you to manage DNS for services across all clusters belonging to a specific group defined in Rancher. This simplifies management when dealing with many clusters.

The system uses the clusterId provided by Rancher’s management API to uniquely identify each cluster it needs to interact with. This ID is typically in the format c-<cluster-id>:<p-<project-id>> when referencing a specific project within a cluster.

If you want to expose a service that isn’t using a standard ingress controller but rather a NodePort, Global DNS can also pick up those NodePort IPs and ports, though this is generally less robust for production workloads.

The next logical step after setting up Global DNS is often exploring how to manage TLS certificates across these multi-cluster deployments, which Rancher’s integrated cert-manager or external certificate management solutions can help with.