ExternalDNS keeps application DNS records aligned with the endpoints declared in Kubernetes. For example, when a service's external address changes, it can update the corresponding record at your DNS provider instead of requiring a manual edit. It is useful for teams publishing many changing services. It configures the provider rather than answering DNS queries itself, and its scope and deletion policy determine which real records it is allowed to change.
Current guidance
The Kubernetes SIGs project publishes the current ExternalDNS chart. It reads selected Kubernetes resources and reconciles their intended names and targets with a configured DNS provider. Provider configuration and supported resource sources depend on the selected release; the historical list of providers and example version are not a current compatibility guarantee.
Begin with a controlled zone, a record inventory and dry-run output. Set domain or zone filters, source selection and provider credentials narrowly enough for the intended workload. Choose the reconciliation policy explicitly: create-only adds records, upsert-only also updates them, and sync permits deletions. The TXT registry records ownership alongside DNS data. Keep its owner identifier stable during normal operation; a deliberate change requires migrating ownership, not just changing the identifier or deleting TXT records.
Test creation, target changes and deletion of one disposable name, checking the authoritative provider as well as a resolver. Distinguish a reconciliation error from ordinary TTL and cache delay. Preserve existing record values and ownership metadata before changing controllers, and plan how to restore both. Give each cluster a distinct owner identifier when clusters share a zone. The documented --migrate-from-txt-owner option can help transfer ownership, but combining it with sync is unsafe when other clusters still use that old owner: their records can be treated as orphans and deleted. Verify the migration in dry-run mode and isolate or coordinate shared ownership before enabling deletions.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://github.com/kubernetes-sigs/external-dns and returned HTTP 200 on 2026-10-09. GitHub does not mark kubernetes-sigs/external-dns archived or disabled; this does not establish active maintenance, support or compatibility. GitHub resolves the old repository identity to kubernetes-sigs/external-dns. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Original publication: 2018-09-09T23:33:41+00:00. Preserved for context. Commands, versions, prices and results below reflect the original research.
ExternalDNS synchronizes exposed Kubernetes Services and Ingresses with DNS providers. Inspired by Kubernetes DNS, Kubernetes’ cluster-internal DNS server, ExternalDNS makes Kubernetes resources discoverable via public DNS servers. Like KubeDNS, it retrieves a list of resources (Services, Ingresses, etc.) from the Kubernetes API to determine a desired list of DNS records. Unlike KubeDNS, however, it’s not a DNS server itself, but merely configures other DNS providers accordingly, e.g. AWS Route 53 or Google CloudDNS.
In a broader sense, ExternalDNS allows you to control DNS records dynamically via Kubernetes resources in a DNS provider-agnostic way.
The FAQ contains additional information and addresses several questions about key concepts of ExternalDNS.
The Latest Release: v0.5
ExternalDNS’ current release is v0.5. This version allows you to keep selected zones (via –domain-filter) synchronized with Ingresses and Services of type=LoadBalancer in various cloud providers:
- Google CloudDNS
- AWS Route 53
- AWS Service Discovery
- AzureDNS
- CloudFlare
- DigitalOcean
- DNSimple
- Infoblox
- Dyn
- OpenStack Designate
- PowerDNS
- CoreDNS
- Exoscale
- Oracle Cloud Infrastructure DNS
From this release, ExternalDNS can become aware of the records it is managing (enabled via –registry=txt), therefore ExternalDNS can safely manage non-empty hosted zones. We strongly encourage you to use v0.5 (or greater) with –registry=txt enabled and –txt-owner-id set to a unique value that doesn’t change for the lifetime of your cluster. You might also want to run ExternalDNS in a dry run mode (–dry-run flag) to see the changes to be submitted to your DNS Provider API.
Technical Requirements
Make sure you have the following prerequisites:
- A local Go 1.7+ development environment.
- Access to a Google/AWS account with the DNS API enabled.
- Access to a Kubernetes cluster that supports exposing Services, e.g. GKE.
How is ExternalDNS useful to me?
You’ve probably created many deployments. Typically, you expose your deployment to the Internet by creating a Service with type=LoadBalancer. Depending on your environment, this usually assigns a random publicly available endpoint to your service that you can access from anywhere in the world.
But dealing with IPs for service discovery isn’t nice, so you register this IP with your DNS provider under a better name, most likely one that corresponds to your server name. If the IP changes, you update the DNS record accordingly.
Those times are over! ExternalDNS takes care of that last step for you by keeping your DNS records synchronized with your external entry points.
ExternalDNS’ usefulness also becomes clear when you use Ingresses to allow external traffic into your cluster. Via Ingress, you can tell Kubernetes to route traffic to different services based on certain HTTP request attributes.
But there’s nothing that actually makes clients resolve those hostnames to the Ingress’ IP address. Again, you normally have to register each entry with your DNS provider.
Kubernetes Incubator
This is a Kubernetes Incubator project. The project was established 2017-Feb-9 (initial announcement here). The incubator team for the project is:
- Sponsor: sig-network
- Champion: Tim Hockin (@thockin)
- SIG: sig-network
The post ExternalDNS appeared first on kubedex.com.
Sources & further reading
Spotted something that needs another look?
Help improve this page →