Separating Authoritative DNS Zones Between Internal and External

TL;DR

A robust DNS naming concept separates internal resolution from publicly authoritative edge services. Internal and External DNS Zones have different visibilities, resolution paths, and security boundaries. Instead of synchronizing zones retroactively, companies should define namespaces, responsibilities, and data flows separately from the outset.

Introduction

The most common mistake in DNS architecture is not an incorrect record but an unclear area of responsibility. When internal service names, administrative endpoints, and public applications reside in the same authoritative zone, every change becomes a security and operational issue. An internal name can inadvertently become publicly visible; a public record can be answered by internal resolvers through an unexpected path. The central architectural decision is therefore: Which zone is internally authoritative, which zone is provided authoritatively for public edge services, and where do the DNS security boundaries lie?

1. Cut namespaces by visibility rather than organization

Internal DNS Zones and External DNS Zones should not merely be different views of the same database. They serve different purposes. An internal zone, for example, contains names for cluster endpoints, private backends, management services, or service discovery. These pieces of information are needed by internal resolvers and should not be part of public DNS responses.

External Zones, on the other hand, contain names that must be resolvable from the internet. These include public web applications, APIs, or mail and verification records. A publicly authoritative service is responsible for these names, capable of answering queries independently of internal resolvers.

A clean DNS naming concept thus separates not only records but ideally also domains or subdomains. api.example.com can point publicly to the edge, while api.internal.example.com is resolvable only internally. The naming conveys a technical property: visibility and responsibility.

2. Define resolution paths as security boundaries

Split-Horizon DNS becomes problematic when it is understood only as a convenience feature for different responses. The resolution path is crucial. Internal resolvers should reach internal zones directly or through clearly defined forwards. Public resolvers, however, should only see the External Zones intended for internet services.

This separation reduces the risk of internal target addresses, hostnames, or infrastructure information leaking outside. It also prevents internal clients from taking an unnecessary detour through internal special rules for public names. A public service should be reachable from internal networks either via the intended public name and the edge or through a specifically defined internal name. Mixing both paths unintentionally complicates troubleshooting and security assessment.

For the ayedo Edge Cloud, this distinction is relevant because Anycast DNS and Multi-Provider DNS can form the public authoritative path. The External Zone provides the names for public edge services. Internal zones remain under their own DNS responsibility and do not automatically become part of this public namespace.

3. Deliberately assign authoritative data

The question “Which zone contains the record?” should be answered by a responsibility decision, not by technical convenience. Records for public services belong in the External Zone if their resolution is necessary for accessibility via the edge. This includes names pointing to public Anycast endpoints or needed for TLS and domain validation.

Internal backend names, private addresses, and cluster-internal service names, on the other hand, belong in Internal Zones. They are not published just because a public service technically accesses them. The Edge Cloud does not necessarily require the internal naming structure for external accessibility. Backend Cloaking supports precisely this decoupling: The public DNS name points to the edge while the actual backend topology remains hidden.

It is also important not to organize changes through retroactive synchronization of both zones. Synchronization can create divergent states, unclear deletion responsibilities, and unintended publications. It is better to have a clear source per record category and a clear transition between public frontend and internal backend.

4. Operations and governance at the zone boundary

The separation of zones directly impacts operations. For External Zones, TTLs, failover behavior, DNSSEC, or provider concepts and changes to public services must be considered. Internal zones, on the other hand, follow the requirements of platform operations, service discovery, and private networks. Both areas have different change frequencies and different failure consequences.

Permissions should also be aligned at the zone boundary. A team operating a public API endpoint does not automatically need access to internal infrastructure zones. Conversely, a platform team should be able to manage internal names without directly executing public DNS changes. This separation improves traceability and reduces the impact of faulty automation.

With multiple DNS providers or an edge platform like ayedo, authoritative responsibilities must also be explicitly documented. Multi-Provider DNS can increase the availability of the public path; it does not replace a naming concept. Technical redundancy is only robust if all involved authoritative systems serve the same clearly defined External Zone.

Practical scenario: Public API with private backend

A company operates an API in a Kubernetes cluster with an external provider. Internally, there are names like orders-api.cluster.internal.example.com and several private backend addresses. Publicly, only api.example.com should be visible.

In the External Zone, api.example.com points to the ayedo Edge Cloud. There, TLS termination, WAF, DDoS protection, and load balancing can occur. The backend address and internal naming structure are not published. Internal clients either use the public name via the intended edge path or a separate internal name, depending on routing and security requirements. The key is that both paths are consciously modeled. An automatically synchronized record set would not be a simplification here but an additional source of error.

FAQ

Is Split-Horizon DNS always necessary?

No. Separate domains or subdomains are often simpler. Split-Horizon DNS is useful when the same name needs different responses depending on the request context.

Do backend records belong in the External Zone?

No. The frontend name required publicly is necessary. Backend names and private addresses should remain in Internal Zones and not be derivable from the public zone.

Can the Edge Cloud replace internal DNS zones?

No. The Edge Cloud provides the public DNS and traffic path. Internal name resolution, service discovery, and private zones remain a separate architectural responsibility.

Conclusion

Internal and External DNS Zones are not mere copies with different responses but separate areas of responsibility. A deliberate DNS naming concept defines visibility, resolution paths, and responsibilities before operations. The ayedo Edge Cloud can form the authoritative public path for edge services, while internal zones and backend names remain shielded. This results in clearer security boundaries, fewer synchronization risks, and better-controllable operational processes.