Automatically Manage DNS Records from Kubernetes Ingress

TL;DR

Kubernetes Ingress and Gateway configurations already contain the hostnames under which applications should be accessible. External-DNS can translate these declarative specifications into DNS records. To create a consistent public endpoint, the DNS zone, edge routing, and backend configuration must reflect the same desired state.

Introduction

A Kubernetes hostname is not yet a reachable service. An Ingress or a Gateway can specify that api.example.com belongs to a particular application, but without a matching DNS record, this host remains invisible. Conversely, a DNS entry can point to a publicly accessible endpoint for which there is no appropriate routing rule in the cluster. These separate states create hard-to-detect errors: incorrect backends, orphaned records, or TLS configurations that do not match the host. The central architectural decision is therefore: Kubernetes hosts, DNS publication, and edge endpoints must be treated as a cohesive chain—with clear responsibility for each layer.

1. Kubernetes Hosts as a Declarative Source

Ingress rules and Gateway API resources describe under which host HTTP requests should be processed. The hostname is not just a routing attribute. It also defines the expected public identity of a service and is often used for TLS certificates, access controls, and observability.

This is where the pattern behind External-DNS comes into play: A controller observes relevant Kubernetes resources and derives desired DNS records from their host definitions. Changes to spec.rules.host or Gateway listeners can automatically adjust the DNS state. If a team removes a resource, the associated record can also be removed from management—depending on the chosen protection and ownership mechanisms.

It is important to delineate: The Kubernetes host is the declarative intent, not automatically the correct target address. Responsibility, allowed zones, and the assignment to the public endpoint must be clearly defined.

2. DNS Publication is a Controlled Reconciliation

Automated DNS management does not mean publishing every detected host specification publicly without verification. In production environments, reconciliation requires rules: Which namespaces are allowed to create records? Which DNS zones are permitted? How are competing resources handled? And when can a record be deleted?

In this model, External-DNS is the link between Kubernetes and a DNS provider. The desired configuration is read from Ingress or Gateway objects and compared with the actual managed DNS state. Provider-independent usage is possible, provided the deployed provider is supported and ownership is clearly regulated. This is particularly relevant in multi-cluster or multi-team environments: Without clear responsibility, multiple controllers can modify or overwrite the same record.

The DNS layer must also distinguish between publicly accessible and internal applications. A hostname from a development namespace should not end up in a public zone just because it exists in the cluster.

3. The Edge Cloud as the Target of the Public Endpoint

In an edge architecture, the DNS record should not point directly to a hidden backend. Instead, it refers to the public endpoint of the edge cloud. There, Anycast-based Layer-4 and Layer-7 load balancing, TLS termination, web application firewall, DDoS protection, and backend health checks can be centrally effective for the host.

The technical chain is thus: A host is declared in Kubernetes, from this declaration a DNS target is created, and this target leads to the ayedo Edge Cloud. The edge then assigns the host to the appropriate routing and backend. Backend cloaking prevents the actual cluster endpoints from having to be used as public DNS targets.

This separation is also relevant for Kubernetes clusters outside of ayedo Managed Kubernetes. An own cluster or a cluster with another provider can use the same edge entry. Kubernetes remains responsible for workload and routing definitions; DNS and public traffic entry are operated as independent platform areas.

4. Consistency Requires Status, Tests, and Operational Rules

The critical operational case is not the successful publication of a new record, but a partially updated configuration. If an Ingress is created first but DNS is updated with a delay, the service may only be reachable through a temporary or unresolved state. Conversely, if DNS is removed before edge routing is cleaned up, configurations and resources remain unnecessarily.

Therefore, the lifecycle should be observable: Does the host exist in the Kubernetes object? Was the expected record published? Does it point to the intended edge endpoint? Is the host active at the edge and do the health checks reach a valid backend? These checks do not necessarily have to take place in a single tool but should be considered as a cohesive operational process.

For companies, this reduces manual DNS changes and configuration drift. At the same time, the responsibility for validation and permissions increases. Otherwise, a faulty host could be automatically published. It is therefore sensible to use namespaces, zones, and resource types as clear governance boundaries—supplemented by change reviews for particularly critical domains.

Practical and Operational Scenario

A team publishes payments.example.com via a Gateway in their own Kubernetes cluster . The Gateway defines the host and refers to the payment service. External-DNS recognizes the declared host configuration and updates the responsible DNS provider. The record does not point to a node IP but to the public ayedo edge endpoint. The edge handles TLS termination, checks the backend, and forwards traffic to the cluster.

If the Gateway is deleted, the process must also consider the DNS and edge states. A controlled reconciliation removes or deactivates the host only when ownership and protection rules allow it. Without these rules, a deleted Kubernetes service can remain as an orphaned DNS record.

FAQ

Is External-DNS itself a DNS server?

No. External-DNS synchronizes desired DNS records from Kubernetes resources with a supported DNS provider. Authoritative DNS resolution remains the responsibility of this provider.

Can Gateway API resources be used instead of Ingress?

Yes, provided the deployed External-DNS configuration and the Gateway controller evaluate the relevant listener and host definitions. The exact support depends on the specific implementation.

Does the DNS record need to point directly to the Kubernetes cluster?

No. In a preceding edge architecture, the record can point to the public edge endpoint. The backend remains hidden and is only accessed through the edge.

Conclusion

Kubernetes DNS records are robust when they are not viewed in isolation as DNS automation. Ingress and Gateway hosts describe the desired application interface; External-DNS publishes this intent; the edge cloud provides the controlled public entry. The ayedo Edge Cloud connects DNS, Anycast reachability, protection, and backend routing—regardless of where the Kubernetes cluster is operated. A verifiable lifecycle across all layers remains crucial.