External DNS

​

Coverage Matrix

​

External DNS Overview

External DNS automatically manages DNS records for Kubernetes Services and Ingresses, eliminating the need for manual updates whenever an IP address or hostname changes. By watching the cluster’s API for resource changes, External DNS updates records on external providers (e.g. AWS Route 53, Google Cloud DNS, Azure DNS, Cloudflare) in real time. This ensures services remain accessible under consistent domain names without manual intervention, reducing configuration drift and minimizing downtime from outdated DNS entries.

​

Chkk Coverage

​

Curated Release Notes

Chkk tracks official External DNS releases and distills changes into concise summaries. Operators see highlights of breaking changes, security fixes, and new features relevant to DNS automation, rather than combing through lengthy changelogs. This helps teams quickly assess whether an upgrade might impact configuration flags, provider APIs, or critical security patches.

​

Preflight & Postflight Checks

Before an upgrade, preflight checks verify that External DNS is set up correctly—ensuring provider credentials are valid, domain filters or annotations remain compatible, and resource limits are adequate. After the upgrade, postflight checks confirm DNS records synchronize properly and that no new error messages (e.g. API rate limits or authentication failures) appear. This validation guards against misconfigurations that could break record updates.

​

Version Recommendations

Chkk continuously monitors External DNS’s lifecycle, flagging older releases as they near end-of-life or become incompatible with newer Kubernetes APIs. It suggests stable releases that align with your cluster version and known provider constraints, helping you avoid versions with critical bugs or deprecations. Staying on recommended releases ensures reliable DNS management and reduces the risk of unsupported features.

​

Upgrade Templates

Chkk offers two strategies for upgrading External DNS: in-place and blue-green. In-place applies rolling updates to the existing deployment, leveraging Kubernetes rolling strategies to maintain uptime. Blue-green spins up a parallel External DNS deployment, tests it against DNS providers, and cuts over traffic after validation. This method offers near-zero downtime and a straightforward rollback if unexpected issues arise.

​

Preverification

For major changes or critical environments, Chkk’s preverification simulates the upgrade in a sandbox. It checks whether your DNS provider credentials, flags, or domain filters remain valid on the new version. It also evaluates whether DNS updates succeed without hitting rate limits or lingering propagation delays. This catch-issues-early approach reduces production surprises.

​

Supported Packages

No matter if External DNS was deployed with Helm, Kustomize, or raw YAML, Chkk aligns its upgrade steps with your current method. It supports private registries and custom-built images, ensuring that your images, security settings, and Helm/Kustomize overlays remain intact throughout the upgrade. This integration keeps your workflow consistent while benefitting from Chkk’s checks and recommendations.

​

Common Operational Considerations

• Ownership Conflicts: TXT-based ownership prevents ExternalDNS from altering records it doesn’t “own.” Manually added DNS entries or multiple ExternalDNS instances using the same TXT owner ID can cause record flapping or collisions.
• RBAC and IAM Gaps: Missing permissions in Kubernetes RBAC or cloud provider IAM can silently block record changes. Audit the ServiceAccount and associated roles—particularly in multi-tenant, production-grade setups.
• Garbage Collection Issues: In “upsert-only” mode, ExternalDNS won’t remove obsolete records. Switch to “sync” (with caution), or manually clean DNS zones to avoid stale entries exposing decommissioned services.
• Large-Cluster Overheads: ExternalDNS scales poorly if it must track thousands of Services or Ingresses. Use —provider-cache-time and consider filtering by domain, zone ID, or namespace to reduce API calls and memory usage.
• Multi-Cluster Collisions: Multiple clusters writing to the same zone must use unique TXT owner IDs or separate subdomains. Otherwise, they risk overwriting each other’s records and causing unpredictable DNS behavior.

​

Additional Resources

• External DNS Documentation
• External DNS Releases