Scaling Kubernetes DNS with ExternalDNS and Route 53

As our Kubernetes platform scaled across multiple environments and regions, DNS management started becoming a bottleneck. What initially worked as a centralized setup began to introduce operational challenges such as API throttling and increasing manual effort.

In this article, I’ll walk through how we evolved our DNS architecture using ExternalDNS with AWS Route 53 and the improvements we achieved.

What is ExternalDNS?

ExternalDNS is a Kubernetes controller that automatically manages DNS records based on Kubernetes resources such as Ingress, Services, and custom resources like VirtualServer or DNSEndpoint.

It continuously watches the cluster and ensures that DNS records in providers like AWS Route 53 are kept in sync with the desired state defined in Kubernetes.

In simple terms, it acts as a bridge between Kubernetes and your DNS provider, allowing DNS to be managed declaratively through Kubernetes instead of manual updates.

The challenge: centralized DNS doesn’t scale

Initially, all DNS records were managed within a single AWS Route 53 account. Over time, this led to several issues:

• API rate limiting (5 requests per second per account)


• Frequent throttling during automated updates


• Heavy reliance on manual DNS changes and tickets


• Accumulation of stale or unused DNS records


• Tight coupling between infrastructure and DNS operations

Although a temporary increase to 20 RPS was provided, it was not a sustainable long-term solution.

The solution: distributed DNS with ExternalDNS

To address these challenges, we redesigned our DNS architecture with the following approach.

Environment-based DNS distribution

We separated DNS management across AWS accounts based on environments (Dev, Stage, Prod). This reduced contention and improved scalability.

Kubernetes-driven DNS using ExternalDNS

We deployed ExternalDNS across clusters with the following configuration:

--policy=sync

--registry=txt

--txt-prefix=edns.

--txt-owner-id=<unique-per-cluster>

Key capabilities

Automated DNS lifecycle

DNS records are now automatically:

• Created when resources are deployed


• Updated when configurations change


• Deleted when resources are removed

This removes the need for manual DNS management and ensures DNS always reflects the actual cluster state.

Self-service DNS for application teams

Application teams can now manage DNS directly through Kubernetes:

• Deploying an Ingress or VirtualServer creates DNS records


• Deleting the resource removes the corresponding DNS

This significantly reduces dependency on infrastructure teams and speeds up delivery.

Safe multi-cluster ownership

By using a unique txt-owner-id per cluster:

• Each cluster manages only its own records


• Prevents accidental deletion or modification across clusters

This is especially important when the same domain is shared across multiple regions (for example, dev-east and dev-west).

Automatic cleanup

With --policy=sync, ExternalDNS ensures:

• No orphaned DNS records remain


• DNS always reflects the current state of the cluster

Avoiding API rate limits

Distributing DNS across multiple AWS accounts:

• Reduces load per account


• Eliminates throttling issues

This directly addresses the limitations of the previous centralized setup.

Seamless cluster migration

This architecture simplifies cluster migrations:

• Deploy resources in a new cluster → DNS records are created


• Remove resources from the old cluster → DNS records are deleted

DNS effectively follows the application without requiring manual coordination.

Real impact

After implementing this model, we observed:

• Faster and smoother deployments


• Elimination of manual DNS tickets


• Cleaner and more consistent DNS state


• Safer multi-cluster operations


• A scalable architecture ready for future growth

Key takeaways

• Centralized DNS becomes a bottleneck at scale


• ExternalDNS with sync policy enables a declarative DNS model


• Ownership isolation is critical in multi-cluster environments


• Distributed DNS architecture improves both performance and reliability

What’s next

This foundation also enables:

• Easier migration to managed Kubernetes platforms (EKS, AKS, GKE)


• Standardized DNS management across environments


• Improved observability and governance

If you are running Kubernetes at scale and still relying on centralized or manual DNS processes, this approach is worth exploring.