DNS delegation architectures for multi-forest environments

Why DNS delegation becomes the hard part in multi-forest AD

In a single forest, DNS design is mostly a question of internal authority: AD-integrated zones, secure dynamic
updates, SRV record registration, and replication scope. In a multi-forest model, the question expands:
which forest is authoritative for which parts of the namespace, and how do other forests
find, trust, and cache those answers.

If the delegation model is wrong, the symptoms look like “intermittent trust issues,” “Kerberos failures,”
“random DC locator problems,” or “name resolution works from some subnets but not others.” Those are almost
always second-order effects of:

• ambiguous zone authority (two places think they own the same name)
• referrals that can’t be followed (firewalls, missing glue, broken recursion)
• replication scope mismatch (data exists but not where the query lands)
• incompatible update policies (secure updates expected, but zone not AD-integrated)
• operational drift (manual records and conditional forwarders diverge over time)

Core DNS concepts you must anchor before designing delegation

Authority, delegation, and glue

A zone is authoritative for a portion of the namespace. Delegation is the act of placing NS records in a parent
zone that tell resolvers: “for this child zone, go ask these servers.” If the delegated child zone’s name servers
are inside the child zone, the parent also needs glue records (A/AAAA) so resolvers can reach
them without already having the answer.

Recursion vs iteration

Your AD DNS servers usually act as both authoritative servers (for internal zones) and recursive resolvers
(for everything else). Delegation architecture decides whether clients/servers will:

• Iterate through delegations (walking from parent to child using referrals), or
• Use targeted forwarding (conditional forwarders) to jump directly to the right servers.

AD-integrated zones and replication scope

With AD-integrated DNS, zone data is stored in AD and replicated using AD replication, with a configurable scope:
forest-wide DNS application partition, domain-wide partition, or custom. This is powerful internally, but it is
not magic across forests: AD replication does not cross forest boundaries. So cross-forest name
resolution needs classic DNS mechanisms: delegation, forwarding, or secondary zones.

Secure dynamic updates and record ownership

Forest A can securely update Forest A’s AD-integrated zones. Forest B cannot (and should not) perform secure
dynamic updates in Forest A’s zone unless you intentionally build that trust and permissions model. Delegation
designs that “expect dynamic updates across forests” typically create fragile exceptions and long-term drift.

The design space: what you are really deciding

When you choose a DNS delegation architecture for multi-forest environments, you are committing to answers for:

• Namespace strategy: shared internal root, separate internal roots, or split-brain patterns
• Authority boundaries: which forest owns which zones and subzones
• Resolution path: delegation/referrals vs conditional forwarding vs secondary zones
• Operational ownership: who provisions, monitors, changes, and troubleshoots the DNS links
• Security controls: what’s allowed to be discovered cross-forest and how to restrict it
• Failure mode: what breaks when a forest’s DNS is unreachable and how to degrade safely

The rest of this article builds practical architectures from these constraints, rather than listing DNS features.

Multi-forest scenarios and what DNS must enable

Scenario A: trusts and authentication flows

Forest trusts rely on locating domain controllers in each forest via DNS. Clients and DCs need to resolve SRV
records in the other forest’s domains (for example _ldap._tcp.dc._msdcs under the target domain
namespace). If that resolution fails or points to unreachable DCs, you will see:

• Kerberos referral failures
• logon delays and fallback to NTLM
• trust validation failures
• GC and UPN suffix resolution inconsistencies

Scenario B: application/service discovery across forests

Cross-forest apps often depend on stable hostnames, sometimes even SRV records. DNS must be predictable for both
humans and services. “It resolves from some places” is unacceptable in distributed authentication models.

Scenario C: mergers, acquisitions, and transitional coexistence

The DNS model must accommodate change: new domains, renamed prefixes, decommissioned DCs, and gradual network
integration. Delegation architectures that require massive coordination for small changes become liabilities.

Architecture 1: classic parent/child delegation (referral-based)

This is “real DNS.” A parent zone delegates child zones to the authoritative name servers in the owning forest.
Resolvers follow referrals iteratively.

When it fits

• You have a clear, hierarchical namespace (for example corp.example.com delegating to subzones)
• You want DNS to work without maintaining forwarders on every resolver
• Network paths permit DNS referrals (UDP/TCP 53) to authoritative servers across forests
• You can manage glue and zone cutovers cleanly

Common patterns

• Single internal parent zone owned by a “shared services” DNS tier, delegating subdomains to
  each forest’s DNS.
• External public namespace mirrored internally (split-brain), with internal delegations for
  forest-owned subdomains.

Operational realities and pitfalls

• Glue correctness is non-negotiable. If the parent delegates to name servers inside the child
  zone, missing glue means resolution can deadlock.
• Firewalling breaks referrals. Delegation assumes resolvers can reach authoritative servers.
  Many enterprises allow DNS only to a small resolver tier, not to every DC.
• Referral behavior varies by resolver. Some clients only query their configured resolvers and
  won’t “walk” delegations themselves; your recursive resolvers must do it reliably.
• Delegation does not replicate records. It only points to the authority. Monitoring must include
  reachability and correctness of NS targets.

How to implement cleanly

• Establish an internal parent zone managed by a designated team (or shared services)
• Delegate subzones to each forest’s DNS servers (prefer dedicated DNS, not every DC)
• Ensure TCP 53 is allowed as well as UDP 53 (zone transfers aren’t needed, but DNS responses can fallback)
• Keep NS sets minimal and stable; rotate servers with a controlled process
• Use short enough TTLs during transition, then increase once stable

Architecture 2: conditional forwarding between forests (resolver-based)

Conditional forwarders tell your DNS resolvers: “for queries ending in forestB.internal, forward to
these IPs.” This is not delegation in the strict DNS hierarchy sense, but it is the most common enterprise
technique for cross-forest name resolution because it works well with segmented networks.

When it fits

• Clients can only talk DNS to local resolvers (common in secured networks)
• Cross-forest authoritative servers aren’t reachable directly from everywhere
• You want explicit control over which zones can be resolved cross-forest
• You can maintain a resolver-to-resolver trust relationship operationally

Key design decision: where forwarders live

• On AD DNS (DCs): simplest, but increases dependency between authentication tier and resolver
  tier.
• On dedicated recursive resolvers: cleaner separation, better caching, easier monitoring, and
  often better performance under load.

Must-have guardrails

• Forward only what you mean to share. Forward the specific forest root zones (and sometimes
  only the AD-specific zones if you want to limit exposure).
• Use multiple targets per forwarder. Point to at least two reliable resolvers/authoritatives in
  the other forest.
• Define failure behavior. “Forward first, then recurse” can leak queries externally if you’re
  not careful. Ensure your recursion policy and root hints strategy match your security stance.
• Cache and TTL management matters. Bad TTL choices create long-lived misroutes during DC
  migrations.

Operational drift risks

Conditional forwarding is configuration-heavy if you do it ad-hoc. The drift problem shows up when forests add
child domains or rename zones: some resolvers get updated, others don’t. The fix is architectural:

• standardize a small number of resolver tiers per forest
• centralize forwarder configuration (GPO for DC DNS, or infra-as-code for resolver appliances)
• monitor forwarder health and query success rate

Architecture 3: secondary zones across forests (data-based)

A secondary zone copies zone data from the primary/master via zone transfers (AXFR/IXFR). In cross-forest
environments, this is used to make a subset of names “local” without relying on forwarding or referrals at query
time.

When it fits

• You need fast resolution even when the other forest is intermittently reachable
• You can open zone transfer paths (TCP 53) between specific servers
• You want a stable replica of a zone for a limited set of critical records

Why it’s tricky for AD zones

Many AD environments use AD-integrated zones where the “primary” is effectively the AD replication system.
Secondary zones can still work, but you need to choose specific masters that will allow transfers and keep that
list maintained.

Security and change control

• Zone transfers are data exfiltration if mis-scoped. Restrict transfers to explicit IPs.
• Sign transfers where possible, and monitor for unexpected transfer attempts.
• Use this model for limited, purpose-driven zones (not “everything”).

Architecture 4: stub zones (referral-lite with automation)

Stub zones hold only NS (and necessary glue) for a zone, and periodically refresh from a master. They can reduce
manual NS maintenance compared to hard-coded delegations or forwarders, while still allowing referral-style
resolution.

When it fits

• You want “delegation behavior” but with automated NS updates
• You can reach authoritative masters for stub refresh
• You want to avoid secondary zone full-data replication

Watch-outs

• Stub refresh relies on connectivity; treat it like a dependency with monitoring
• Some organizations confuse stub zones with conditional forwarding; they behave differently
• Ensure your resolvers follow referrals and can reach target authoritative servers

Choosing the right model: a practical decision framework

Start with network reality

If your clients can only reach local resolvers, you’re effectively designing resolver-to-resolver integrations,
which favors conditional forwarding or secondary/stub strategies on the resolver
tier. Pure delegation is elegant but assumes broader reachability.

Define what must be shared cross-forest

Not everything should be resolvable everywhere. For forest trusts and authentication, you typically need:

• target forest domain zones (A/AAAA of DCs)
• the AD-specific locator zones (SRV under the domain namespace and _msdcs)
• optionally, select application zones

If you forward or replicate entire internal namespaces when you only need AD locator records, you expand attack
surface and troubleshooting scope unnecessarily.

Minimize “shared ownership”

The fastest way to create DNS chaos is to make multiple teams jointly responsible for the same zone.
Delegation architectures should keep ownership crisp:

• each forest owns its authoritative zones
• a shared tier owns only the parent/root zone where delegation occurs
• cross-forest links are contracts (forwarder targets, transfer masters) with change control

Common delegation patterns in real enterprises

Pattern 1: shared internal root with forest subdomains

You run an internal namespace like internal.example. Forest A is a.internal.example,
Forest B is b.internal.example. A shared parent zone delegates to each forest.

• Pros: clean hierarchy, easy to reason about, scalable for new forests
• Cons: shared parent is a critical dependency; glue and NS correctness must be managed tightly

Pattern 2: separate roots per forest with forwarding

Forest A is corpA.local and Forest B is corpB.local (or two separate internal domains).
There is no parent-child relationship, so you use conditional forwarders between resolver tiers.

• Pros: minimal coupling, fits segmented networks, explicit sharing
• Cons: configuration sprawl if not centralized; needs disciplined operations

Pattern 3: split-brain public domain with forest partitions

Public: example.com. Internal: also example.com, but with internal-only subdomains
delegated to forests (for example ad.example.com or corp.example.com).

• Pros: consistent naming, user-friendly, aligns with certificates and SaaS integrations
• Cons: strict hygiene required to avoid leaking internal records externally

AD-specific DNS zones: what must resolve for trusts to behave

For cross-forest trusts, the “must resolve” set is usually not huge, but it must be correct everywhere it matters.
The critical record types are:

• SRV records for DC locator: _ldap._tcp, _kerberos._tcp,
  and site-specific variants
• GC locator SRVs when applicable: _ldap._tcp.gc._msdcs and related records
• A/AAAA records for the DC hostnames referenced by SRV targets
• _msdcs zone behavior, especially in modern AD where it is typically a separate zone

Your delegation/forwarding model must ensure both the SRV query and the A/AAAA follow-up query succeed. Many
“it resolves SRV but still fails” incidents are actually follow-up address lookups that fail due to missing
forwarding for the host zone or inconsistent zone cuts.

Security posture: what DNS sharing can accidentally expose

DNS is not authentication, but it is discovery. If Forest A can resolve all of Forest B’s internal names, you have
effectively given Forest A a directory of hostnames and often service topology. In regulated environments, you
should treat cross-forest DNS as a controlled interface.

• Prefer least-sharing: only forward/replicate the zones required for the trust and business
  function.
• Protect recursion: do not allow arbitrary clients in one forest to use DNS servers in another
  forest as open resolvers.
• Audit: log query volumes and unusual patterns across the forest boundary.
• Consider DNSSEC where feasible: not always practical internally, but it changes the integrity
  story if you can deploy it consistently.

Failure modes and how to design for graceful degradation

A delegation architecture must be judged by what happens when something is partially broken. Ask these questions
explicitly and document the answers:

• If Forest B’s DNS is unreachable from Forest A’s resolvers, do we fail fast or hang on timeouts?
• Do we have multiple forwarding/NS targets in different sites to avoid site-specific partitions?
• Are TTLs tuned so that transient outages don’t thrash, but changes still converge within a known window?
• Can we validate “trust health” by synthetic queries that mirror DC locator behavior?

In practice, the best designs rely on a small set of hardened resolver tiers per forest with
monitoring and redundancy, rather than letting every DC be an integration point.

Operational playbook: what to standardize so this stays healthy

1) Define integration endpoints

Pick dedicated DNS endpoints that other forests depend on: either dedicated recursive resolvers or a subset of DC
DNS servers designed for that role. Don’t point cross-forest forwarding to “whatever DC is nearby.”

2) Centralize configuration

• Forwarder configuration should be managed centrally (policy or configuration management)
• Delegation NS records in parent zones should have change control and peer review
• Zone transfer allow-lists should be explicit and tracked

3) Monitor the right queries

Don’t just ping a DNS server. Monitor the queries that matter:

• _ldap._tcp.dc._msdcs.<domain> from each forest
• A/AAAA for the DC targets returned
• site-aware records if you use AD Sites
• latency and SERVFAIL/NXDOMAIN rates on cross-forest lookups

4) Document TTL policy and change windows

If you migrate DCs or rename services, TTLs determine how long the old reality persists. Having a published TTL
policy lets you plan cutovers without guesswork.

Recommended reference architectures

Reference architecture 1: segmented enterprise with dedicated resolver tiers

• Clients query only local resolvers
• Each forest has redundant recursive resolver tiers
• Conditional forwarders exist between resolver tiers for specific zones only
• Authoritative AD zones stay inside each forest
• Monitoring runs synthetic DC locator queries cross-forest

This is the most common “works in the real world” design because it aligns with security segmentation and gives
clean ownership boundaries.

Reference architecture 2: hierarchical internal namespace with shared services parent

• A shared internal parent zone delegates forest-owned subdomains
• Resolvers can follow referrals to authoritative servers in each forest
• Glue and NS sets are carefully managed and monitored
• Forwarding is used only as an exception, not the core mechanism

This is elegant and scalable when the network allows it, but it requires stronger discipline around the shared
parent zone and referral reachability.

Reference architecture 3: limited replication for critical zones

• Use secondary zones or stubs for a small number of critical cross-forest zones
• Keep transfers locked down to explicit servers
• Use this to reduce latency or survive transient WAN issues

Best when you have a narrow set of critical names and strong reasons to avoid runtime forwarding dependencies.

Troubleshooting mental model: trace the authority chain

When cross-forest resolution fails, troubleshoot in this order:

1. What exactly is being queried? (name, record type, suffix search behavior)
2. Which resolver is answering? (client DNS settings, resolver tier selection)
3. Does that resolver know where to go? (forwarder, delegation, stub, root hints policy)
4. Can it reach the next hop? (UDP/TCP 53, routing, firewall, NAT, MTU)
5. Is the target authoritative and consistent? (zone data, NS records, DC registration health)
6. Are caches lying? (TTL, negative caching, stale records during migrations)

Avoid starting with “restart DNS.” In multi-forest environments, most failures are architectural mismatches or
boundary reachability issues, not single-server service crashes.

Closing guidance

A good DNS delegation architecture for multi-forest environments does three things consistently:
it keeps authority boundaries crisp, it makes cross-forest resolution paths explicit and monitorable, and it
degrades predictably when one side is unhealthy.

If you want a default recommendation that holds up in most secured enterprises:
use dedicated recursive resolver tiers per forest with conditional forwarding for the minimal required
zones, and treat those forwarders as a formal interface with monitoring and change control. Reach for
pure hierarchical delegation only when your network and governance model can genuinely support referral-based DNS
end-to-end.