Provisioning DNS Zones Reproducibly with Terraform

TL;DR

DNS configuration is production-relevant infrastructure and should not depend on manual changes in individual interfaces. With Terraform , zones and DNS records can be managed declaratively, verified, and rolled out reproducibly. Prerequisites include a clean state, clear responsibilities, controlled changes, and a process for discrepancies between code and actual configuration.

Introduction

Manually created DNS records rarely cause immediate problems. It becomes critical when multiple environments, teams, or zones are involved, and no one can be sure which configuration is definitive. A forgotten record, a differing TTL, or a change made directly on the platform might only be noticed during the next rollout. DNS with Terraform treats zones not as one-time settings but as versioned infrastructure. This improves traceability and repeatability but also shifts responsibility to the deployment process: state, reviews, dependencies, and discrepancies must be consciously managed.

1. Model DNS as Declarative Infrastructure

Terraform describes the desired state of a DNS zone in configuration files. This includes the zone itself and A, AAAA, CNAME, MX, or TXT records, for example. The key is separating the desired configuration from individual change commands. An entry is not “created now” but defined as part of the target state.

The Terraform plan compares this target state with the stored state and the currently accessible platform configuration. This makes planned changes visible before they are applied. This is particularly relevant for DNS records, as a technically small intervention can have direct impacts on accessibility, certificate validation, or email delivery.

In the ayedo Edge Cloud, this management affects the public DNS entry point before applications and APIs. Zones and records can thus be integrated into the same controlled change process as other infrastructure components. The Edge Cloud then provides the DNS function; Terraform defines which configuration should apply there.

2. State, Plan, and Apply are Operational Processes

The [Terraform] state is not a trivial working file. It maps the association between resources in the code and objects in the ayedo Edge Cloud. If it is lost, overwritten, or changed uncoordinated by multiple processes, Terraform can no longer reliably assess the actual state. The state must therefore be protected, versioned, or centrally managed and locked for parallel changes.

The plan is a control stage, not an optional trial run. In a review, it should show which zone or DNS records are changed, deleted, or newly created. Only then does apply follow in the intended environment. For productive zones, an automated apply without review is risky, especially if records with short TTL or failover-relevant significance are affected.

A robust process separates responsibilities: changes are made in the repository, reviewed, and transparently approved. Access data should not be in the [Terraform] files. Additionally, the process should indicate whether a plan is based on the current state. Outdated plans could otherwise execute changes that are based on an outdated foundation.

3. Cleanly Map Dependencies and Multiple Environments

DNS configuration often consists of dependencies. A record refers to an external service, a subdomain delegates to another zone, or an entry only makes sense when a target system is ready. Terraform can derive dependencies from resource references. Where these relationships are not directly visible in the model, the configuration must explicitly and understandably map them.

For multiple environments, a common zone with changing values should not simply be used. Better are clearly separated variables, states, or configuration areas for development, staging, and production. This prevents an apply for a test environment from inadvertently changing productive DNS records. At the same time, it must be defined which parts are central: delegations and common base zones can be managed differently than environment-specific subdomains.

The ayedo Edge Cloud can be used as a provider-independent public entry point, while backends are in ayedo Managed Kubernetes , an own cluster, or with another provider. This separation does not make DNS configuration easier but clearer: Terraform manages the desired public namespace, while the backend infrastructure remains a separate responsibility.

4. Treat Manual Changes as Controlled Exceptions

A direct change in the DNS platform is not automatically wrong. It becomes a problem if it remains permanently outside the intended change process. Terraform recognizes such a deviation as drift in the next plan. Depending on the configuration, the plan can reset the manual value, adopt it, or prompt for correction. None of these options are safe if the team does not know the cause of the deviation.

Therefore, a clear rule is needed for emergency changes: who is allowed to make them, how they are documented, and when they are transferred to the code. A manual record that remains permanently in the system is not a reliable solution. If a change is deliberately managed outside of Terraform , this responsibility must be explicitly modeled, for example, through separate zones or defined exclusions.

This also applies to ayedo Edge Cloud and multi-provider DNS scenarios. The more systems involved in name resolution, the more important clear owners and a recognizable source of truth are. Reproducibility does not mean automating every change. It means that a defined state can be traceably restored at any time.

Practical and Operational Scenario

A company operates the application app.example.com in production and a separate staging environment. The productive zone is managed in its own [Terraform] state, the staging subdomain in a second. A release additionally requires a TXT record for validation. This record is defined as a dependent resource and only released together with the release.

An administrator manually changes the productive CNAME record because a backend was moved at short notice. The next plan shows the deviation. The team first checks whether the change should apply permanently. If so, the [Terraform] code is adjusted and planned again. If not, apply restores the documented target state. Without this process, it would remain unclear which configuration prevails in the next deployment.

FAQ

Can Terraform change DNS records immediately and without review?

Technically, an apply can automate changes. For productive zones, however, the plan should be reviewed and approved, as even small changes can affect accessibility and dependent services.

What happens with a manual change?

Terraform recognizes the deviation as drift, provided the resource is managed in the state. The next plan shows whether the change should be reset or transparently adopted in the code.

Does every environment need its own [Terraform] state?

Not necessarily, but separate states reduce the risk of unintended changes. Especially production and non-production environments should be clearly isolated from each other.

Conclusion

DNS with Terraform is primarily a decision for traceable operational processes. The technical benefit does not arise solely from declarative files, but from protected state, reviewed plans, clean environment boundaries, and a defined approach to manual drift. For DNS zones in the ayedo Edge Cloud, this approach creates a reproducible foundation, regardless of where the actual backends are operated. Thus, DNS becomes a controlled component of the platform architecture, rather than a hard-to-verify individual configuration.