This repository provides a structured basis for a DNS, DHCP and IP address management workshop and the resulting modernization strategy.
The workshop is designed to establish:
- A factual current state
- A business and operational baseline
- Agreed modernization outcomes
- A target operating model
- A target architecture
- Data authority and source of truth rules
- Critical workflows to prove
- Governance and security requirements
- A phased implementation roadmap
- Clear ownership, decisions and next steps
The result should be a decision document, not only a record of discussion. Statements should be supported by inventories, measurements, configuration evidence, diagrams, logs, interviews or explicit assumptions.
This repository is a reference checklist, not a mandatory workshop form. Enterprises should use the topics to shape their own notes, diagrams, registers and decision documents. The only fixed interface is the minimum handover package required by the solution evaluation stage.
This repository is one part of a three document lifecycle:
ddi-workshopestablishes the current state, target state, business and operational outcomes, target operating model, architecture, data authority and critical workflows.ddi-questionnaireevaluates candidate platforms and vendors against the approved requirements and workflows.ddi-migration-planexecutes the approved design and selected solution through controlled migration waves, validation and rollback.
The workshop can begin with incomplete evidence, but the following minimum information is required to make the sessions productive.
| Input | Minimum content |
|---|---|
| Scope sponsor | Named sponsor and decision authority |
| Business and technical scope | Organizations, regions, environments, services and explicit exclusions |
| Current platform inventory | Main DNS, DHCP and IPAM platforms and owners |
| Architecture evidence | At least a current high level service and network diagram |
| Operational evidence | Main workflows, incidents, service pain points and support responsibilities |
| Security context | Applicable policies, audit needs and known security concerns |
| Known initiatives and constraints | Cloud, network, Active Directory, data center, sourcing and contractual dependencies |
| Stakeholder availability | Representatives who can explain current operation and approve target decisions |
Missing evidence should be recorded as an action with an owner and due date rather than replaced by assumptions.
Minimum Output To ddi-questionnaire
The workshop is ready to hand over to the evaluation framework when it provides the following package.
| Workshop output | Minimum content required by the questionnaire |
|---|---|
| Scope and boundaries | Business units, regions, services, environments, planning horizon and exclusions |
| Current state summary | Platforms, service placement, dependencies, retained third party services and major technical debt |
| Business and operational outcomes | Problems to solve, desired behavior, outcome owner and measure where available |
| Scale and growth assumptions | Current and expected object counts, query and lease rates, sites, regions, cloud environments, administrators and retention |
| Target operating model | Service ownership, administrative boundaries, delegation, change authority and support model |
| Service disposition | Replace, retain, overlay or retire decision for each material service or platform |
| Data authority model | Authoritative source, discovery source, execution point, owner and conflict rule by data domain |
| Target architecture principles | Availability, placement, scale, cloud, integration, security, recovery and lifecycle principles |
| Required integrations | Identity, ITSM, cloud, automation, security, monitoring, reporting and other systems that must exchange data or trigger actions |
| Security and compliance requirements | Required controls, audit, retention, separation of duties and security integration needs |
| Critical workflows | Trigger, actors, approval, execution, validation, audit, error handling and acceptance criteria |
| Mandatory requirements | Content that a suitable solution must support, without requiring a scoring method |
| Risks and constraints | Data quality, migration windows, dependencies, contracts, unresolved assumptions and risk owners |
| Decision log | Approved decisions, open decisions, owners and review dates |
This minimum output becomes the minimum input contract of ddi-questionnaire. The questionnaire should not infer missing target state decisions from product capabilities.
- Detailed current state inventory and diagrams
- Business and operational baseline
- Data quality assessment
- Risk, issue and dependency register
- Phased roadmap and action backlog
- Migration readiness assessment
- Candidate quick wins that do not depend on platform replacement
The workshop does not replace:
- A detailed product evaluation
- A formal procurement process
- Low level design for every component
- A detailed migration runbook
- A change request or production authorization
- Establish facts before proposing products.
- Link technical limitations to measurable operational and business outcomes.
- Avoid savings claims that cannot be supported by a baseline.
- Define authority per data domain rather than declaring one platform authoritative for everything.
- Distinguish the source of authority from the DNS or DHCP execution point.
- Preserve useful local and cloud native operating models where appropriate.
- Automate governed workflows, not uncontrolled changes.
- Design resilience through failure domains, tested recovery and operational readiness.
- Treat DNS security as part of service architecture and security operations.
- Treat legacy retirement as part of modernization completion.
- Record assumptions, decisions, owners and due dates during the workshop.
- Workshop Preparation
- Introduction And Objectives
- Stakeholders And Responsibilities
- Current State Analysis
- Future State Definition
- Operational And Governance Model
- Implementation Strategy
- Workshop Deliverables And Exit Criteria
- Appendix
The scope should be precise enough to prevent the workshop from turning into a general discussion about every network service. It should explain:
- Which business units, regions, legal entities and shared services are included
- Which DNS, DHCP, IPAM, cloud, security and integration domains are included
- Which production, recovery, test, development and lab environments matter
- Which services or organizations are explicitly outside the workshop
- The planning horizon used for scale, lifecycle and investment decisions
- Regulatory, contractual, sovereignty and data residency constraints
- The sponsor, decision authority and architecture authority
- Decisions the workshop may make directly and decisions that require another governance body
A useful scope also identifies adjacent programs that can change the answer, such as cloud transformation, Active Directory redesign, data center consolidation, network segmentation, mergers or managed service transitions.
- Organization chart and IT governance model
- Business units, service owners and operating regions
- Service criticality and operating hours
- Current and planned sourcing model
- Current transformation, cloud and security programs
- Regulatory and contractual obligations
- Current DNS architecture diagrams
- Current DHCP architecture diagrams
- Current IPAM data model and hierarchy
- Network and location diagrams
- Cloud account, subscription and project structure
- Firewall and communication flow documentation
- Active Directory forest, domain and site design
- High availability and disaster recovery documentation
- Monitoring, logging and security integration diagrams
- DNS query rates, latency, failures and availability
- DHCP lease counts, utilization, failover state and failure data
- IPAM object counts, utilization, data quality and growth
- Ticket volume and fulfilment time
- Incident and problem records
- Recovery time and outage records
- Upgrade, patch, backup and maintenance effort
- Professional services and operating costs where available
- Cloud discovery and reconciliation effort
- Security detections and investigation effort
The workshop may be completed in one or more sessions.
| Session | Focus | Main outputs |
|---|---|---|
| 1 | Scope, outcomes and current state | Scope, stakeholder map, initial inventory and evidence gaps |
| 2 | Operational baseline and risks | Baseline, pain points, risk register and modernization triggers |
| 3 | Target operating model | Ownership, authority, governance and workflow boundaries |
| 4 | Target architecture and security | Architecture principles, decisions and security model |
| 5 | Critical workflows and roadmap | Proof scenarios, priorities, roadmap, owners and exit decision |
- Establish a shared and evidence based view of the current DDI environment.
- Identify operational inefficiencies, security exposure, resilience gaps and data quality issues.
- Define business outcomes that can be measured before and after modernization.
- Decide which services should be replaced, retained, observed or governed through overlay management.
- Define the target ownership and governance model.
- Define target architecture principles without prematurely selecting a product.
- Identify the workflows that must be proven before purchase or migration.
- Produce a prioritized action plan with owners and dates.
The following questions must be answered explicitly:
- What problem is the organization trying to solve?
- Which problems are caused by architecture, process, ownership, data or product limitations?
- Which existing services are reliable and should remain?
- Which risks require immediate remediation regardless of a platform change?
- Which outcomes require modernization rather than simple cleanup?
- Which assumptions still require evidence?
- Approved current state or list of unresolved evidence gaps
- Approved modernization outcomes
- Approved target operating model
- Approved architecture principles
- Approved data authority rules
- Approved critical workflows for evaluation
- Approved first implementation phases
- Assigned owners for unresolved items
- Executive or service sponsor
- Network architecture
- DNS operations
- DHCP operations
- IPAM and address planning
- Cloud platform teams
- Active Directory and identity teams
- Network operations
- Security architecture
- Security operations and incident response
- Application and DevOps representatives
- IT service management
- Enterprise architecture
- Compliance, risk and audit
- Procurement and finance where commercial outcomes are in scope
- Project and change management
Stakeholder coverage matters more than a specific table format. Ensure that every decision domain has an identifiable owner and that the workshop includes people who can provide evidence rather than only opinions.
At minimum, establish:
- Who owns the DDI service and its budget
- Who owns DNS namespaces, address plans, DHCP policy and cloud networks
- Who can approve architecture, security and operating model decisions
- Who understands day to day administration and recurring failure modes
- Who represents application, DevOps, Active Directory, cloud and security dependencies
- Who can explain procurement, support and contractual constraints
- Who will accept the outputs for the next lifecycle stage
Global enterprises should distinguish global policy ownership from regional execution. An unnamed team should not be treated as accountable for a decision.
Define at least the following responsibilities:
- Service ownership
- Product ownership
- Architecture authority
- DNS namespace ownership
- IP address plan ownership
- DHCP policy ownership
- Cloud network ownership
- Data ownership
- Security policy ownership
- Change approval
- Incident command
- Disaster recovery decision
- Vendor and contract ownership
Use a RACI or an equivalent model. Avoid assigning collective accountability to an unnamed team.
- Organizational structure and IT governance model
- Business units, departments and operational functions
- Internal IT, service provider and customer facing responsibilities
- Critical services and 24 hour operations
- Outsourcing, insourcing, mergers, divestitures and planned collaboration
- Business continuity obligations
- Classification of locations, including branches, hubs, data centers, recovery sites, edge locations and cloud regions
- Geographic distribution
- Network connectivity and dependencies
- Local autonomy and support capability
- Failure domains and isolation behavior
- Sites with legal or data residency constraints
Review locations by operational characteristics rather than only by site name.
| Location characteristic | Questions to consider |
|---|---|
| Core data center or hub | Which DDI roles run there, what other sites depend on them and what happens when the location is isolated? |
| Branch or campus | Is local DHCP required, is local DNS caching needed and can the site operate during WAN failure? |
| Cloud region | Which native DNS and IPAM services exist, who owns them and how are they reconciled with enterprise data? |
| Edge or intermittently connected site | Which services must remain local, how are changes synchronized and how is stale state detected? |
| Recovery site | Is it continuously active, warm or cold, and has recovery been tested under realistic dependencies? |
| Regulated or sovereign location | Are there restrictions on data location, administration, logging, support access or cross border replication? |
The minimum output is a location model that exposes failure domains, local autonomy, connectivity dependencies and recovery expectations.
- Compute, storage, virtualization and container platforms
- LAN, WAN, SD WAN, VPN and Internet access
- Firewalls, load balancers and network access control
- Monitoring, SIEM, CMDB, ITSM and automation platforms
- High availability and disaster recovery mechanisms
- SaaS and managed service dependencies
Create one authoritative inventory of:
- DNS servers and services
- DHCP servers and services
- IPAM platforms, databases, spreadsheets and scripts
- Address blocks, networks, ranges and subnets
- DNS zones and records
- DHCP scopes, pools, reservations, leases and options
- Cloud networks and DNS services
- Integrations and automation
- Owners and administrators
- Dependencies
- Security policies
- Unsupported or obsolete systems
The inventory should support architecture, risk and migration decisions. For every material component, capture the following information in the organization’s preferred system:
| Inventory dimension | What to understand |
|---|---|
| Service role | Authoritative DNS, recursive DNS, forwarding, DHCP, IPAM, discovery, security, reporting or integration role |
| Product and lifecycle | Product family, version, support state, upgrade constraints and known end of support dates |
| Placement | Site, region, failure domain, hosting model and network dependencies |
| Ownership | Service owner, technical owner, data owner and support provider |
| Managed data | Zones, records, scopes, leases, networks, metadata and cloud resources associated with the component |
| Authority | Whether the component is authoritative, observational, a synchronization target or only an execution point |
| Dependencies | Identity, database, network, storage, monitoring, security, backup, automation and external service dependencies |
| Planned disposition | Retain, replace, govern through an overlay, consolidate or retire |
Do not limit the inventory to appliances. Include scripts, spreadsheets, network device services, cloud native services, managed providers and undocumented operational workarounds.
- Overall DNS hierarchy, delegations, zone transfers and forwarding
- Inventory of authoritative, recursive, forwarding and hybrid servers
- Public DNS hosting and registrar relationships
- Mission critical internal and external zones
- Distribution of zones across services and sites
- Split horizon DNS, views and overlapping namespaces
- Hidden primary, secondary and multi primary patterns
- Anycast, load balancing, clustering and other resilience mechanisms
- Dynamic DNS updates from Active Directory, DHCP, applications and automation
- Internet name resolution path
- Naming conventions and namespace policy
- Cloud native DNS zones and private resolution
- Third party secondary or managed DNS relationships
- Change request and approval process
- Zone and record ownership
- Deployment frequency and lead time
- Emergency change process
- Backup, restore and rollback
- Upgrade and patch process
- Capacity and performance management
- Monitoring from client and service perspectives
- Common incidents and troubleshooting process
- Authentication and authorization for changes
- Logging and monitoring of administrative and dynamic changes
- DNSSEC validation and signing
- Zone transfer and dynamic update protection
- Recursive access control
- Response Policy Zones or equivalent policy controls
- DNS threat intelligence and policy sources
- Detection of tunneling, domain generation algorithms and suspicious domains
- Forensic data available for incident response
- DNS telemetry integration with SIEM and SOAR
- Client to resolver encryption using DoH, DoT or DoQ
- Policy for unauthorized encrypted DNS
- DDoS and random subdomain attack resilience
- Separation of authoritative and recursive functions
- Public domain and registrar security
- Server and zone exports
- Query and response metrics
- Availability reports
- Sample change and audit records
- DNSSEC validation reports
- Security event examples
- Failure and recovery records
- Inventory of DHCP servers, products and versions
- Distribution of scopes, pools and reservations
- Lease policies and utilization
- Failover, clustering or other resilience mechanisms
- Relay topology and helper addresses
- Dynamic and static allocation policy
- Special options for VoIP, PXE, wireless, network devices and other clients
- Site and vendor specific options
- DHCPv6 and prefix delegation
- Integration with DNS, NAC, identity and asset systems
- Device provisioning and automation dependencies
- Scope request and approval process
- Reservation and option ownership
- Lease troubleshooting and history
- Capacity and exhaustion management
- Failover monitoring and recovery
- Backup, restore, upgrade and patch process
- Common incidents and client compatibility issues
- Logging and monitoring of changes and leases
- Administrative authentication and authorization
- Rogue DHCP detection and response
- DHCP snooping and dynamic ARP inspection dependencies
- 802.1X and network access control integration
- Relay trust and Option 82 handling
- Resource exhaustion and denial of service controls
- Sensitive client data retention and access
- Security operations use of lease and identity data
- Server configuration and scope exports
- Relay inventory
- Lease and utilization reports
- Failover status and test results
- Sample client traces
- Audit and security event examples
- Forest, domain and site structure
- Active Directory integrated DNS zones
- Underscore and service location zones
- Replication topology and dependencies
- Secure dynamic DNS update behavior
- Domain controller locator and registration behavior
- DNS client configuration through Group Policy
- DHCP authorization and role delegation where applicable
- Dependency of authentication and application services on DNS and DHCP
- Ownership boundaries between directory, network and DNS teams
- Migration and rollback constraints
- Current address management systems, databases, spreadsheets and scripts
- Address hierarchy and allocation model
- Public, private, IPv6 and overlapping address spaces
- Network classifications and routing contexts
- VLAN, VRF, VXLAN and location relationships
- Number and growth of managed networks and addresses
- Metadata definitions, completeness and consistency
- Ownership and lifecycle states
- Cloud address space and synchronization
- Relationships with DNS, DHCP, devices and applications
- Source of address utilization evidence
- Network and address request process
- Allocation, reservation, reclamation and retirement
- Conflict detection and resolution
- Delegated administration
- Data import, reconciliation and cleanup
- Reporting, capacity planning and audit preparation
- API and automation use
- Backup, restore and recovery
- Role based access control
- Detailed audit trails
- Segregation of duties
- Integration with identity and privileged access management
- SIEM integration
- Encryption and secure access
- Regulatory requirements such as FISMA, GDPR, GMP, HIPAA, PCI DSS or TISAX where applicable
- Regular access and data reviews
- Protection of sensitive ownership and device data
- AWS accounts and Route 53 environments
- Azure subscriptions and DNS environments
- Google Cloud projects and Cloud DNS environments
- Private cloud and virtualization platforms
- SaaS DNS or managed DNS providers
- Microsoft DNS and DHCP
- Open source DNS and DHCP
- Network device DHCP and DNS functions
- Retained vendor platforms
- Ownership and support boundaries
- Current discovery and synchronization
- Overlapping address or namespace risks
- Policy and audit consistency
- Expected replacement, retention or overlay management
Use service disposition to prevent modernization from becoming an automatic replacement exercise.
| Disposition | Appropriate when | Questions that still require an answer |
|---|---|---|
| Retain | The service is reliable, supported and aligned with the target operating model | How will it be governed, monitored, integrated and included in the source of truth? |
| Replace | The service creates unacceptable operational, security, lifecycle or architecture risk | What capability replaces it, how is coexistence handled and when can the source be retired? |
| Overlay | The execution point remains, but enterprise visibility, governance or automation is added | Which system is authoritative, how are conflicts reconciled and what actions may the overlay perform? |
| Retire | The service or data set no longer has a valid consumer | How are dependencies verified, evidence archived and access, licenses and infrastructure removed? |
| Consolidate | Several equivalent services can move to a shared model | Which local requirements must be preserved and which exception process remains? |
Apply disposition separately to management, data authority and execution. A DNS server may remain an execution point while authority and workflow move elsewhere.
Document the current steps, systems, owners, waiting time and failure points for:
- Allocate an IP address
- Allocate a subnet
- Create or change a DNS record
- Create a DNS zone or delegation
- Create or change a DHCP scope
- Create a reservation
- Reclaim an address
- Onboard a cloud account or network
- Onboard an application or branch
- Apply a security policy
- Investigate a DNS or DHCP incident
- Recover from service failure
- ITSM
- CMDB
- Network automation
- Cloud orchestration
- SIEM and SOAR
- Security monitoring
- Observability
- Configuration management
- CI/CD
- Self service portals
- Identity and access management
- Asset and vulnerability management
- Data warehouses and reporting
- AI assistants and agents where relevant
For each integration, understand more than whether a connector exists.
| Integration aspect | Questions to consider |
|---|---|
| Direction | Does the system read, write, request an action, receive an event or exchange state in both directions? |
| Data and action | Which objects, metadata, approvals, events or configuration changes cross the boundary? |
| Interface | Supported API, event stream, message bus, file exchange, database access, agent or customer maintained code? |
| Authority | Which system wins when values conflict, and can the receiving system reject or quarantine a change? |
| Identity and security | How are identities, secrets, certificates, permissions and tenant boundaries handled? |
| Failure behavior | What happens during timeout, duplicate delivery, partial failure, retry or prolonged outage? |
| Scale and timing | What volume, latency and burst behavior must be supported? |
| Ownership and support | Who operates each side, who troubleshoots the boundary and how are upgrades coordinated? |
A product integration is not complete until authority, error handling, observability and support boundaries are understood.
A modernization business case should connect technical limitations to observable outcomes. Record the data source and confidence for every measure. Do not claim savings that cannot be documented.
Measure time spent on:
- DNS and DHCP tickets
- Manual address allocation and changes
- Spreadsheet reconciliation
- Troubleshooting address and DNS conflicts
- Audit preparation
- Cloud resource discovery
- Policy enforcement
- Patches, upgrades and backups
- Threat investigation and incident response
- Disaster and cyberattack recovery
Measure the time and handoffs required to:
- Provision a subnet
- Create a DNS record
- Onboard an application
- Connect a branch
- Allocate cloud address space
- Deploy DNS or DHCP capacity
- Detect and mitigate DNS threats
Document:
- DNS and DHCP incidents
- Configuration errors
- Outages caused by manual changes
- Detection and recovery time
- Systems without high availability
- Untested or inconsistent failover procedures
- Backup and restore test results
- Disaster recovery test results
Evaluate:
- Unmanaged DNS or DHCP services
- Weak administrative controls
- Incomplete audit trails
- Missing or inconsistent DNSSEC
- Limited DNS policy enforcement
- Limited DNS threat visibility
- Limited detection of malicious DNS activity
- Lack of automated mitigation
- Lack of DNS continuity during attacks
- Missing SOC integration
- Uncontrolled use of encrypted DNS
- Security control and compliance gaps
Identify cost and effort associated with:
- Point products
- Legacy appliances
- Open source support
- Homegrown tools
- Professional services
- Cloud management utilities
- Duplicate inventories and reporting
- Bespoke integrations
Enterprises may use their own measurement systems. The workshop should nevertheless establish enough baseline evidence to show whether modernization creates an improvement.
| Measure | Why it matters | Useful evidence |
|---|---|---|
| DNS and DHCP ticket volume | Shows recurring administrative demand and avoidable incidents | ITSM categories, service desk reports and manual request logs |
| DNS and subnet fulfilment time | Exposes waiting time, approval delay and manual handoffs | Request timestamps, workflow logs and interviews |
| Change failure and rollback rate | Indicates control quality and operational risk | Change records, incident links and post change reviews |
| Mean time to detect and restore | Tests observability, ownership and recovery capability | Monitoring events, incident timelines and recovery exercises |
| Address and DNS data exceptions | Shows whether the current inventory can be trusted | Duplicate, stale, overlapping, orphaned and conflicting object reports |
| Unmanaged or unsupported services | Reveals lifecycle and governance exposure | Inventory reconciliation and support status review |
| Automation adoption | Distinguishes available automation from actual operational use | API logs, workflow executions and manual versus automated request counts |
| DNS security visibility | Shows whether DNS can support security detection and investigation | Logging coverage, retained telemetry and investigation records |
| Upgrade and maintenance effort | Identifies operational burden that may not appear in incident data | Maintenance calendars, labor estimates and vendor support history |
Where exact values are unavailable, record the evidence source, confidence and collection action. Do not invent precision.
Evaluate data against:
- Completeness
- Accuracy
- Consistency
- Timeliness
- Uniqueness
- Ownership
- Provenance
- Lifecycle state
Identify:
- Duplicate networks, addresses, records and reservations
- Overlapping address space without routing context
- Stale DNS records
- Orphaned PTR, CNAME, delegation and lease data
- Missing metadata and ownership
- Conflicts between IPAM, DNS, DHCP, cloud and CMDB
- Unsupported or unparseable configuration
- Unknown dependencies
Assess data quality by the decisions and workflows it can safely support.
| Data quality issue | Checks to perform | Potential effect |
|---|---|---|
| Duplicate objects | Duplicate addresses, records, reservations, networks or identifiers across systems | Ambiguous authority and failed imports |
| Overlapping address space | Overlaps within and across VRFs, cloud networks and business units | Incorrect allocation, routing ambiguity and migration conflict |
| Stale data | Records or addresses without recent observation, owner or consumer | False capacity assumptions and risky cleanup |
| Missing ownership or metadata | Objects without accountable owner, purpose, environment or lifecycle | Weak governance and delayed incident response |
| DNS inconsistencies | Lame delegations, missing reverse records, mismatched forward and reverse data, invalid zone content | Resolution failure and application impact |
| DHCP inconsistencies | Overlapping scopes, invalid options, conflicting reservations and unknown relay paths | Client outage or incorrect configuration |
| Discovery mismatch | Observed state differs from the declared inventory | Untrusted source of truth and hidden infrastructure |
| Unsupported data | Source objects have no supported target representation | Transformation, exception handling or retained service requirement |
The workshop does not need to clean every issue. It must identify which issues block evaluation, proof of concept or migration.
Modernization may be justified when several of the following conditions exist:
- Routine changes depend on tickets, spreadsheets and repeated manual work.
- Different systems disagree about addresses, DNS, DHCP or cloud resources.
- Cloud adoption has fragmented visibility and governance.
- Troubleshooting requires searching many consoles and data sources.
- Changes have inconsistent approval, testing, rollback or audit.
- Capacity expansion requires disproportionate appliance, licensing or services effort.
- DNS continuity depends on manual recovery.
- Security teams lack useful DNS context.
- APIs expose insufficient operational capability.
- Unsupported infrastructure or skills create material risk.
Use the organization’s normal risk method, but ensure that the workshop considers at least these themes:
| Risk theme | Questions to examine |
|---|---|
| Service resilience | Are there hidden single points of failure, shared dependencies or untested recovery assumptions? |
| Data authority | Can different systems change the same object, and is there a declared conflict rule? |
| Security exposure | Are administrative interfaces, recursive DNS, dynamic update, zone transfer, DHCP or data exports insufficiently controlled? |
| Lifecycle | Are critical components unsupported, difficult to patch or dependent on scarce skills? |
| Cloud divergence | Can cloud teams create networks and DNS outside enterprise governance, and how is that state discovered? |
| Migration feasibility | Are source formats, custom behavior, lease state, DNSSEC, delegations or change windows likely to constrain transition? |
| Operating model | Are ownership, approvals, incident command and support boundaries unclear? |
| Integration dependency | Could an unavailable ITSM, identity, cloud or automation system block a critical DDI workflow? |
| Vendor and delivery | Are roadmap claims, custom services, licensing assumptions or support boundaries material to the target state? |
| Legacy retirement | Could temporary coexistence become permanent because consumers and dependencies are unknown? |
For each material risk, document cause, consequence, current control, required action, accountable owner and the decision it may influence.
Define a small set of measurable outcomes rather than a long list of generic benefits.
Example outcome areas:
- Reduce fulfilment time and handoffs
- Improve data quality and network visibility
- Increase automation adoption
- Improve DNS and DHCP availability
- Reduce change failures
- Improve recovery time
- Improve DNS threat detection and response
- Reduce overlapping tools and unsupported systems
- Improve cloud governance
- Establish a trusted network data service
Outcomes should describe a change in enterprise behavior, not the purchase of a product. Useful outcome areas include:
| Outcome area | Strong formulation |
|---|---|
| Service delivery | Approved DNS, DHCP and IPAM requests complete through a governed workflow with fewer manual handoffs and observable completion |
| Resilience | Critical name and address services continue through defined site, component and dependency failures, with tested recovery |
| Data quality | Networks, addresses, DNS and DHCP data have declared authority, ownership, provenance and controlled reconciliation |
| Cloud operations | Cloud resources become visible and governable without forcing every cloud service into one execution model |
| Security | DNS and DHCP controls reduce attack surface while telemetry supports detection, investigation and response |
| Delegation | Regional, cloud and application teams can perform approved tasks within explicit resource and policy boundaries |
| Lifecycle | Unsupported systems and temporary workarounds are removed through a dated transition plan |
| Operational efficiency | Repetitive tasks are automated only after approval, validation, audit and failure handling are defined |
Each selected outcome should be connected to a current problem, an accountable owner, evidence of improvement and a review horizon.
Decide:
- Which services will be replaced
- Which services will remain
- Which services require overlay management or visibility
- Which services will be retired
- Which temporary coexistence models are acceptable
- Which teams own service, data and policy
- Which functions are centralized or delegated
- Which functions are automated
- Which approval controls are required
- How cloud teams participate
- Which systems consume DDI data
- How security operations use DNS telemetry
Define:
- Product ownership
- DNS service ownership
- DHCP service ownership
- IP address plan ownership
- Namespace ownership
- Cloud DDI ownership
- Data domain ownership
- Security policy ownership
- Change approval
- Incident and recovery authority
- Vendor and lifecycle management
The operating model should answer who may decide, approve, execute and support each class of change.
| Decision area | Questions the target model must answer |
|---|---|
| IP network allocation | Who owns the address plan, who requests space, who approves exceptions and where is the allocation recorded? |
| DNS namespace and records | Who owns zones, who may create records, which changes require approval and who handles external registrars? |
| DHCP services | Who owns scope policy, relay dependencies, options, reservations and failover operation? |
| DNS security policy | Who owns filtering, logging, threat intelligence, exceptions and incident response? |
| Cloud reconciliation | Who may create cloud networks or zones, which state is imported and how are conflicts resolved? |
| Platform administration | Which duties are separated, how is privileged access reviewed and how are emergency changes controlled? |
| Incident and recovery | Who detects, commands, communicates, restores and authorizes failover or rollback? |
| Product lifecycle | Who owns upgrades, capacity, support cases, roadmap review and technical debt? |
The minimum output is a model that can be translated into roles, access scopes, approval rules, support procedures and evaluation requirements.
For each workflow, classify the intended control level:
- Manual with documented procedure
- Assisted with validation
- Automated with approval
- Automated within guardrails
- Autonomous observation only
- Autonomous remediation with explicit rollback and human authority
Do not automate a workflow until authority, validation, failure handling and audit are defined.
A source of truth is not simply the platform with the most objects. It is a governed model that declares which source is accepted as correct for each data domain or field.
- Authoritative source: State accepted as correct for a defined data domain.
- Discovery source: State observed from infrastructure.
- Execution point: DNS, DHCP or cloud service that applies or publishes configuration.
- Consumer: System that reads or acts on governed data.
- Reconciliation rule: Decision applied when sources disagree.
The authoritative source and execution point may be different by design.
- IP addresses and prefixes
- DNS zones and records
- DHCP scopes, reservations and leases
- VLANs and VXLANs
- VRFs
- Devices and interfaces
- Users and identities
- Applications and services
- Cloud resources
- Locations and ownership
- Relationships and dependencies
Define authority per data domain and, where necessary, per field. Common candidates are shown below, but the enterprise must make its own decision.
| Data domain | Common candidate authorities | Common execution or observation points | Decision required |
|---|---|---|---|
| IP networks and prefixes | Enterprise IPAM, cloud platform, network source of truth | Routers, cloud networks, discovery tools and CMDB | Which system approves allocation, and how are externally created networks reconciled? |
| IP addresses | IPAM, DHCP service, cloud platform or application workflow | DNS, DHCP leases, discovery, virtualization and cloud inventory | Which state is authoritative for static, dynamic and observed use? |
| DNS zones and records | DDI platform, Active Directory, infrastructure as code, cloud DNS or managed DNS | Authoritative servers, registrar and cloud DNS services | Who may change each namespace and how are dynamic records handled? |
| DHCP scopes and reservations | DDI platform, DHCP service or automation workflow | DHCP servers and relay paths | Where is configuration authored and how is active lease state treated? |
| Ownership metadata | IPAM, CMDB, service catalogue or application inventory | Reports, APIs and discovery enrichment | Which fields are mandatory and which system may update them? |
| Device observations | Discovery, network management, endpoint or cloud inventory | IPAM, CMDB and security analytics | Observed state should normally be identified as observation unless explicitly promoted through reconciliation. |
The matrix should also define provenance, review process, conflict handling, stale data behavior and audit ownership.
Define:
- Match keys
- Field level authority
- Accepted duplicates
- Merge rules
- Rejection rules
- Stale data policy
- Manual review thresholds
- Dry run and approval
- Audit and rollback
- Data quality reporting
Define:
- Availability requirements
- Geographic placement
- Failure domains
- Capacity and scalability
- Cloud connectivity
- Security controls
- Disaster recovery
- Upgrade strategy
- Logging and monitoring
- Ecosystem connectivity
- Management plane isolation behavior
- Data retention
- Nonproduction and test environments
- DNS and DHCP services continue safely during management plane outages.
- Authoritative and recursive DNS roles are separated where risk requires it.
- Service placement follows client, latency, sovereignty and failure domain requirements.
- Management, DNS, DHCP, discovery, reporting and security scale according to their different needs.
- Cloud native and third party services can remain where they have an explicit role and governance model.
- Configuration is policy driven and auditable.
- Recovery, upgrade and rollback are designed and tested.
- The architecture supports IPv4 and IPv6.
- No licensing or telemetry dependency creates an unrecognized service failure.
- Centralized and distributed authority model
- Internal, external and cloud namespace boundaries
- Active Directory integration
- Recursive resolution path
- Forwarding policy
- Anycast, secondary, load balancing and clustering choices
- DNSSEC signing and validation
- DNS security policy enforcement
- Encrypted DNS policy
- Logging and security telemetry
- Cloud and hybrid resolution
- Failure and recovery behavior
- Centralized or distributed service model
- Relay topology
- Failover and high availability
- Lease and allocation policy
- Scope segmentation
- DHCPv6 and prefix delegation
- DNS update ownership
- Network access control integration
- Cloud DHCP responsibilities
- Failure and recovery behavior
- Address hierarchy and routing context
- IPv4 and IPv6 planning
- Metadata and ownership
- Lifecycle states
- Network source of truth scope
- Discovery and reconciliation
- Cloud integration
- API and workflow automation
- ITSM integration
- Capacity, analytics and reporting
- Data quality controls
- Supported API and event patterns
- Identity and service account model
- ITSM request and approval
- Cloud orchestration
- Network automation
- SIEM and SOAR
- CMDB and asset management
- Observability
- CI/CD and infrastructure as code
- Self service
- Data export and analytics
- Error, retry and rollback behavior
- Federated authentication and MFA
- Role based access and resource scope
- Separation of duties
- Service account governance
- Privileged and emergency access
- Complete audit trail
- Recursive access control
- Authoritative service protection
- DNSSEC signing and validation
- Secure updates and transfers
- Threat intelligence and DNS policy
- Tunneling and malicious domain detection
- DDoS and random subdomain resilience
- Security operations integration
- Logging, privacy and retention
- Encrypted DNS governance
- Administrative security
- Rogue server detection integration
- Relay and Option 82 trust
- DHCP snooping and access control dependencies
- Lease and identity telemetry
- Resource exhaustion controls
- Data classification
- Metadata access
- API security
- Backup encryption
- Retention and deletion
- Data provenance and integrity
- Regular access and data quality review
Review security as a lifecycle across prevention, detection, response and recovery.
| Control area | Enterprise considerations |
|---|---|
| Administrative access | Strong identity, least privilege, separation of duties, scoped delegation, privileged session control and break glass governance |
| DNS availability and integrity | Role separation, access control, secure transfer and update, response rate controls, diversity, monitoring and tested recovery |
| Recursive DNS use | Client authorization, recursion boundaries, forwarding policy, encrypted DNS governance and protection from abuse |
| DNS security operations | Query and response visibility, retention, threat intelligence, policy exceptions, investigation workflow and SIEM or SOAR integration |
| DHCP protection | Trusted relay paths, rogue server controls, exhaustion detection, Option 82 policy, lease visibility and recovery from state inconsistency |
| IPAM data protection | Data classification, API security, export control, backup encryption, retention, provenance and regular access review |
| Platform lifecycle | Vulnerability management, patching, configuration baselines, support access and secure decommissioning |
| Recovery | Protected backups, restore testing, configuration versioning, dependency validation and clear incident authority |
Controls should be tied to actual threats, required evidence and operational ownership rather than product feature names.
The proof stage must test real customer workflows rather than generic demonstrations.
- Import and reconcile representative IPAM, DNS, DHCP and cloud data.
- Discover cloud resources across an environment in scope.
- Allocate a subnet through an API or approved service request.
- Create a DNS record through an ITSM workflow.
- Create a DHCP scope and verify relay and client behavior.
- Apply delegated administration to a regional, cloud or application team.
- Simulate a DNS or DHCP service failure.
- Roll back a configuration change.
- Integrate DNS security events with security monitoring.
- Assess DNS security risk using representative traffic or logs.
- Export governed data without vendor specific lock in.
Describe workflows in the organization’s preferred notation. A useful workflow definition should make the following visible:
- The business purpose and event that starts the workflow
- The requester, service owner, approver and execution identity
- The authoritative source for every object created or changed
- The DNS, DHCP, IPAM, cloud or third party execution points
- Required input, policy checks, naming or allocation rules and conflict checks
- Approval and separation of duties requirements
- The normal sequence across portals, ITSM, APIs, automation and DDI services
- Validation performed after deployment at the actual execution point
- Audit evidence linking request, approval, change, validation and any rollback
- Expected behavior for duplicate requests, retries, partial failure and unavailable dependencies
- Rollback or controlled exception behavior
- Performance, expiry, ownership and support expectations
For example, a DNS record workflow should consider namespace ownership, duplicate detection, TTL policy, IPAM relationship, approval, authoritative deployment, resolver validation, audit linkage, expiration and rollback. A generic product demonstration that only creates a record in a GUI does not prove the workflow.
A workflow is proven only when:
- Representative data is used.
- Preconditions and authority are explicit.
- Identity and approval are enforced.
- The result is validated at the execution point.
- User and machine actions are auditable.
- Failure and retry behavior are controlled.
- Rollback is demonstrated where required.
- Acceptance criteria are met.
- Roles, responsibilities and approval workflows
- Resource scoped delegation
- Separation of duties
- Standard change models
- Emergency change model
- Version control for templates and automation
- Peer review for high risk changes
- Cloud governance
- Access review and recertification
- Service account lifecycle
Define:
- Service catalogue
- Request fulfilment
- Incident management
- Problem management
- Change enablement
- Release and deployment
- Capacity management
- Availability management
- Continuity and disaster recovery
- Configuration and asset management
- Knowledge management
- Vendor management
- Service health and availability
- DNS latency, errors and capacity
- DHCP utilization, lease rate and failover state
- IPAM data quality and utilization
- Workflow completion and failure
- Queue, deployment and synchronization state
- Security events and policy actions
- Backup, restore and recovery tests
- Access and change audit
- Regulatory evidence
- Cloud visibility and unmanaged resources
Track:
- Ticket reduction
- Provisioning time
- Address utilization
- Change failure rate
- Mean time to detect and resolve
- Unmanaged asset discovery
- DNS availability and performance
- Security detections and response
- Policy compliance
- Adoption of automated workflows
- Data quality exceptions
- Legacy service retirement
| Cadence | Review | Participants | Outputs |
|---|---|---|---|
| Daily or operational | Service health and incidents | Operations and security | Actions and escalations |
| Weekly | Changes, capacity and workflow failures | Service owners | Priorities and corrective actions |
| Monthly | KPI, risk and data quality | Product, architecture and operations | Improvement backlog |
| Quarterly | Access, resilience, security and roadmap | Governance board | Decisions and investment priorities |
| Annual | Strategy and recovery validation | Executive sponsor and owners | Updated target state and roadmap |
The roadmap should be phased. Modernization is not complete when new servers are installed. It is complete when data, workflows, operations and legacy retirement meet agreed outcomes.
- Complete the DDI and dependency inventory.
- Identify owners and administrators.
- Identify unsupported systems.
- Measure operational, service, security and cost baselines.
- Assess data quality.
- Record evidence gaps.
- Inventory is accepted or unresolved gaps have owners and dates.
- Baseline measures have defined sources and confidence.
- Material risks are recorded.
- Decide replace, retain, overlay and retire scope.
- Define service and data ownership.
- Define automation and approval boundaries.
- Define cloud participation.
- Define consumers of DDI data.
- Define use of DNS telemetry by security operations.
- Ownership and decision rights are approved.
- Data authority domains are approved.
- Service disposition is approved.
- Define availability and recovery.
- Define geographic placement and failure domains.
- Define capacity and scalability.
- Define cloud connectivity.
- Define security controls.
- Define upgrade and rollback.
- Define monitoring and ecosystem integration.
- Architecture principles and material decisions are approved.
- Open design decisions have owners and dates.
- Requirements are ready for product evaluation.
- Select representative data and use cases.
- Define acceptance criteria.
- Test import and reconciliation.
- Test end to end automation.
- Test service failure and recovery.
- Test delegation and audit.
- Test security integration.
- Mandatory workflows pass or have accepted conditions.
- Gaps, cost and support dependencies are documented.
- The selection recommendation is evidence based.
Recommended sequence:
- Establish the governed network data model.
- Import and reconcile data.
- Deploy visibility or overlay management for retained services.
- Migrate noncritical DNS and DHCP services.
- Validate performance, workflows and operations.
- Migrate critical services.
- Retire legacy tools and temporary coexistence.
- Optimize workflows and policies.
The detailed wave plan belongs in ddi-migration-plan.
- Compare results with the approved baseline.
- Correct data quality and workflow exceptions.
- Review security efficacy.
- Expand automation only after controls are proven.
- Retire remaining legacy services.
- Update architecture and operating model decisions.
Quick wins may include:
- Correct high impact DNS and DHCP vulnerabilities.
- Remove unsupported software or close exposed administration.
- Standardize backup and monitoring.
- Establish ownership for critical zones and address space.
- Clean high risk duplicate or stale data.
- Integrate critical logs with security monitoring.
- Document and test recovery.
- Standardize naming, metadata and allocation policy.
A quick win must have an owner, expected outcome and validation. It should not create a competing target architecture.
Use the enterprise’s normal backlog or project system. The workshop should leave behind actions in at least these categories:
- Immediate risk reduction that does not depend on platform selection
- Evidence collection needed to complete the current state
- Decisions required before product evaluation
- Data cleanup required before proof of concept or migration
- Architecture and operating model work
- Critical workflow preparation
- Integration and security dependencies
- Migration readiness and legacy retirement prerequisites
Every action should state the problem or outcome, accountable owner, dependency, expected completion evidence and timing. Avoid actions such as “investigate further” without a decision or deliverable.
Record decisions in the organization’s existing architecture or governance repository. Each decision should explain:
- The question that required a decision
- Options considered
- Chosen direction and rationale
- Decision authority
- Affected services, data domains and lifecycle stages
- Assumptions or evidence used
- Conditions, exceptions and review triggers
The decision log should travel with the handover package so that the questionnaire and migration plan do not reinterpret workshop intent.
An assumption is acceptable only when it is visible and time bounded. Capture:
- What is believed but not yet proven
- Why the evidence is unavailable
- What evidence or decision will validate it
- The consequence if it is false
- Who owns resolution and by when
- Which requirement, architecture choice or migration activity depends on it
High impact assumptions should become explicit evaluation conditions or migration entry gates rather than remaining workshop notes.
- Scope and stakeholder map
- Current state architecture and inventory
- Business and operational baseline
- Data quality assessment
- Risk, issue, dependency and assumption registers
- Business outcomes and target measures
- Target operating model
- Service disposition decisions
- Source of truth and data authority matrix
- Target architecture principles and decision log
- Target security model
- Critical workflow definitions and acceptance criteria
- Requirements and acceptance criteria for the questionnaire
- Phased roadmap and action backlog
- Migration readiness gaps
The workshop is complete when:
- Scope and exclusions are accepted.
- The current state is accepted or evidence gaps have owners and dates.
- Baseline measures are defined with data sources and confidence.
- Business outcomes have accountable owners and target measures.
- Replace, retain, overlay and retire decisions are recorded.
- Target operating model and data authority rules are approved.
- Target architecture principles are approved.
- Mandatory requirements are ready for evaluation.
- Critical proof of concept workflows have acceptance criteria.
- Migration constraints and major risks are documented.
- Actions, owners and due dates are agreed.
Transfer the following package to ddi-questionnaire. The item names match the minimum input contract in that repository.
| Handover item | Minimum content | Acceptance check |
|---|---|---|
| Scope and boundaries | Business units, regions, services, environments, planning horizon and exclusions | Evaluation boundaries are unambiguous |
| Current state summary | Platforms, service locations, integrations, dependencies, retained services and major technical debt | Compatibility, coexistence and migration requirements can be derived |
| Business and operational outcomes | Problem, desired behavior, owner and measure where available | Product evaluation can test business and operational relevance |
| Scale and growth assumptions | Current and expected object counts, query and lease rates, sites, regions, cloud environments, administrators and retention | Capacity, placement, licensing and growth can be evaluated consistently |
| Target operating model | Ownership, delegation, approval, support and escalation | Governance requirements can be written without vendor assumptions |
| Service disposition | Replace, retain, overlay or retire per material service | The questionnaire knows what must be managed, observed, replaced or retired |
| Data authority model | Authority, discovery source, execution point, conflict rule and owner per data domain | Source of truth and reconciliation requirements are explicit |
| Target architecture principles | Availability, placement, scale, cloud, integration, recovery, security and lifecycle | Architecture evaluation has approved design boundaries |
| Required integrations | Identity, ITSM, cloud, automation, security, monitoring, reporting and other systems in scope | Integration requirements and proof scenarios are complete |
| Security and compliance requirements | Administrative, DNS, DHCP, IPAM, logging, retention, separation of duties and security integration controls | Security evaluation has a clear baseline |
| Critical workflows | Scenario, actors, data, approval, success criteria, failure behavior and required evidence | Demonstrations and proof of concept tests can be prepared |
| Mandatory requirements | Required capabilities and constraints | Requirements are based on the target state rather than a generic feature list |
| Risks and constraints | Data quality, dependencies, timing, contracts and unresolved decisions | Conditions can be evaluated explicitly |
| Decision log | Approved decisions and open items with owners and dates | Conflicting assumptions are visible |
The evaluation framework should accept the workshop output when:
- The scope and target outcomes are approved.
- Service disposition is known for every material platform in scope.
- Ownership and authority are defined well enough to evaluate governance and reconciliation.
- Architecture principles are clear enough to reject structurally unsuitable solutions.
- Critical workflows include observable acceptance criteria.
- Open assumptions have owners and decision dates.
The workshop does not need to produce a complete low level design. It must provide enough approved content to evaluate solutions consistently.
The migration plan should receive its formal minimum input from the completed evaluation framework. The following workshop artifacts remain supporting inputs and should be preserved without reinterpretation:
- Current state architecture and inventory
- Service disposition decisions
- Business and operational baseline
- Target operating model
- Data authority and reconciliation rules
- Target architecture and security principles
- Success measures and service objectives
- Migration constraints, risks and dependencies
- Legacy retirement objectives
- Decision, assumption and action logs
- Authoritative source: The source whose state is accepted as correct for a defined data domain or field.
- Current state: The observed environment, processes, risks and performance before modernization.
- Discovery source: A system that observes state but is not automatically authoritative.
- Execution point: The service that publishes or applies DNS, DHCP or cloud configuration.
- Source of truth: A governed set of authoritative data domains with ownership, provenance and reconciliation rules.
- Target architecture: The approved structural design and architecture principles.
- Target operating model: The approved ownership, governance, process and automation model.
- Workflow: A request or event from initiation through approval, execution, validation, audit and failure handling.
- AD: Active Directory
- API: Application Programming Interface
- CI/CD: Continuous Integration and Continuous Delivery
- CMDB: Configuration Management Database
- DDI: DNS, DHCP and IP address management
- DDNS: Dynamic DNS
- DHCP: Dynamic Host Configuration Protocol
- DNS: Domain Name System
- DNSSEC: Domain Name System Security Extensions
- DoH: DNS over HTTPS
- DoQ: DNS over QUIC
- DoT: DNS over TLS
- DR: Disaster Recovery
- IPAM: IP Address Management
- ITSM: IT Service Management
- MFA: Multi Factor Authentication
- NAC: Network Access Control
- RACI: Responsible, Accountable, Consulted and Informed
- RBAC: Role Based Access Control
- RPZ: Response Policy Zone
- SIEM: Security Information and Event Management
- SOAR: Security Orchestration, Automation and Response
- VRF: Virtual Routing and Forwarding
- VXLAN: Virtual Extensible LAN