← Cloud projects

Cloud · Architecture Concept

DNS, DHCP & IPAM Architecture

Keep hybrid name resolution and address management predictable by designing IP ownership, DHCP scopes, authoritative DNS, and forwarding paths before networks are connected.

PlatformCloud
DomainNetworking
LevelFoundation
Last reviewed2026-09-19
Use whenMaintain reliable name resolution and predictable address management across on-premises and cloud networks.
Key decisionPlan address space before connectivity
Key conceptsDNS · DHCP · IPAM
Cost focusManaged resolver services
On this page

Building blocks

DNSDHCPIPAMForwardersResolver rules

Design goal

Avoid overlapping address space, ambiguous DNS ownership, and fragile forwarding paths across enterprise and cloud networks.

Success criteria

  • Avoid overlapping address space
  • Document ownership of networks and DNS zones
  • Create deterministic DNS forwarding paths
  • Separate dynamic client addressing from infrastructure addressing

Architecture

Use centrally governed address plans, resilient DNS services, scoped DHCP, and documented forwarding between enterprise and cloud DNS resolvers.

Architecture flow

  • IPAM owns address plans
  • DHCP allocates approved client ranges
  • DNS resolves enterprise zones
  • Conditional forwarding connects cloud/private namespaces
IPAMDHCPDNSHybrid ResolverCloud Zones
IPAM
DHCP
DNS
Hybrid Resolver
Cloud Zones

Architecture decisions

Decision

Plan address space before connectivity

Why

Overlapping CIDR ranges make hybrid routing and service integration much harder to operate.

Trade-off

Up-front IP planning reduces future routing conflicts, but reserves address space that may appear underused in the short term.

Decision

Make DNS forwarding explicit

Why

Document which resolver is authoritative for each namespace and where conditional forwarding occurs.

Trade-off

Deterministic forwarding improves troubleshooting, but creates resolver dependencies that must be redundant and documented across network boundaries.

Security

Protect the control and data paths deliberately. Restrict administrative access, protect dynamic DNS updates, and audit changes to zones, scopes, and reservations.

Availability

Design for the failure domain that must be survived. Run redundant DNS and DHCP services for networks that require continuous name resolution and address allocation.

Cost drivers

  • Managed resolver services
  • Appliance/VM compute
  • Logging
  • Cross-network DNS traffic where metered

Design assumptions

  • Enterprise IP ownership can be centrally governed

Implementation plan

  1. Define one source of truth for address ownership, environment/site hierarchy, subnet allocation, and reserved ranges before connecting networks.
  2. Design DHCP scopes, exclusions, reservations, relay paths, and failover behavior around the actual client networks that need dynamic addressing.
  3. Define authoritative DNS zones, ownership, record-registration behavior, and which teams are allowed to change each namespace.
  4. Create conditional forwarding/resolver paths between enterprise and cloud namespaces with redundant targets and explicit routing dependencies.
  5. Enable query/IPAM logging where required and test forward/reverse resolution, DHCP allocation, overlap detection, and resolver failure.

Validate the design

  • Resolve representative forward and reverse records from each connected namespace.
  • Fail one resolver/DNS service and confirm clients continue through the designed redundant path.
  • Attempt or detect an overlapping address allocation and confirm IPAM prevents or surfaces it before connectivity is established.
  • Request DHCP leases for representative clients and verify reservations, exclusions, options, and relay paths behave as designed.

Architecture basis

Continue a learning path