Introduction
DNS is one of the most critical components of modern IT infrastructures. Nevertheless, it is often only considered when problems arise. Especially when automating TLS certificates via ACME, solutions tend to emerge that work in the short term but become difficult to maintain and insecure over time. A common pattern is distributing DNS access credentials across many systems. This increases the attack surface and makes changes hard to track.
The goal of this setup is to retain automation while centralizing control over DNS changes. The focus is on clear responsibilities, minimal permissions, and traceable processes.
Architecture Overview
The architecture deliberately separates multiple components: clients, resolvers, authoritative DNS servers, dedicated ACME DNS servers, and a central gateway. This separation ensures that not every system has direct access to critical components.
All DNS queries are first routed through resolvers, which determine how requests are forwarded. The ACME zone is handled separately and specifically delegated to dedicated DNS servers.
Resolver Layer
Resolvers play a central role in DNS resolution. Clients communicate exclusively with resolvers and have no direct contact with authoritative DNS servers.
This creates a clear separation between usage and management.
Caching is disabled for the ACME zone to ensure that changes are immediately visible and that outdated records do not cause issues.
Dedicated ACME Zone
The ACME zone is intentionally operated separately from the rest of DNS. This keeps certificate processes isolated and prevents them from affecting production operations.
This separation allows access to be controlled more precisely and makes troubleshooting easier.
ACME Gateway
The ACME gateway acts as the central entry point for DNS updates. Applications send their requests to the gateway, which validates them and then performs DNS changes in a controlled manner.
The gateway ensures that only permitted zones are used, that FQDNs are correct, and that TTL values remain within defined limits. Additionally, all changes can be centrally logged.
Kubernetes vs. Traditional Systems
Kubernetes clusters can communicate directly with the ACME DNS servers, as they are already tightly controlled environments. Traditional systems, on the other hand, use only the gateway to perform DNS updates.
Why Knot
Knot DNS provides a compact and clearly structured configuration. This makes setups easier to reproduce and automate. While BIND offers similar capabilities, Knot fits better with an architecture that emphasizes clearly separated components.
Operations and Benefits
Separating components results in clear responsibilities. Issues can be isolated more quickly, and changes can be carried out in a controlled manner. At the same time, the risk is reduced that individual systems can directly influence DNS.
Conclusion
The combination of a resolver layer, isolated DNS, a dedicated ACME zone, and a central gateway leads to a secure and maintainable architecture. The key principle is: access is not distributed, but deliberately centralized.