DDI (DNS, DHCP, IPAM) Management
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
DDI Management within the platform provides network engineers with a unified interface to analyze and modify DNS records, DHCP scopes, and IP address assignments across multiple vendor environments. It acts as an automated assistant that can look up name resolutions, trace delegation paths, check for IP address conflicts, and draft changes for human approval.
The system is built on a "local-first" philosophy, meaning it can be hosted entirely on your own infrastructure to keep sensitive network data secure. To ensure safety, the platform enforces a strict separation between reading data and making changes: while the AI can instantly troubleshoot issues by reading current states, any request to modify the network (such as adding a DNS record) creates a "Change Request" that must be approved by a human before being executed by the automation engine.
Sources: README.md:3-6, CLAUDE.md:120-123, backend/app/agents/ddi/agent.py:12-25
Overview
For a network operations team, this platform simplifies the management of complex DDI environments by acting as a specialized team member—the DDI Agent. It solves the problem of manual, error-prone data entry and fragmented visibility across different DDI vendors like Infoblox, BlueCat, and SpatiumDDI.
Key Capabilities
- DNS Troubleshooting: Trace CNAME delegation paths and reconcile DNS records against actual device inventory.
- DHCP Analysis: Check scope utilization, look up active leases, and detect address conflicts.
- Automated Change Drafting: Authorizes the AI to prepare DNS/DHCP changes (add/modify/delete) without giving it the power to execute them unilaterally.
- Multi-Vendor Support: Standardized connectors for vendors including Infoblox, BlueCat, SpatiumDDI, and AWS Route53.
Design Philosophy
The platform prioritizes security and accountability through the following principles:
- Self-Hosted: Runs on your hardware to ensure data privacy.
- Human-in-the-Loop: Every network change requires a second human to approve it.
- Redaction by Default: Sensitive information (like secret keys in TXT records) is automatically hidden from the AI using a redaction layer.
- Auditability: Every decision made by the AI specialist is explained in plain English and logged for later review.
Sources: README.md:1-12, CLAUDE.md:21-27, backend/app/agents/ddi/agent.py:46-59
Platform Architecture
The platform is composed of seven core components that work together to provide the AI assistant experience. These are typically deployed as containers (isolated software packages) that fulfill specific roles.
System Components
- frontend: The operations console where engineers chat with the AI, view the topology map, and approve changes.
- api: The central brain that handles requests, checks permissions, and manages AI specialist sessions.
- worker: The background engine that runs discovery jobs, takes config backups, and performs DDI analysis without blocking your session.
- postgres: The system of record that stores long-term data like device inventory and the audit log.
- neo4j: A "living topology map" that tracks how every device, subnet, and DNS zone connects to everything else.
- redis: A high-speed messenger used to coordinate work between the API and the background workers.
- ollama: An optional local AI engine that allows the platform to think and reason without sending data to the cloud.
Sources: README.md:19-27, deploy/docker/README.md:10-18
Vendor Plugin System
The platform uses a standardized connector—a "vendor plugin"—for each DDI provider. This ensures that whether you are interacting with an Infoblox appliance or a BlueCat Address Manager, the platform normalizes the output into a consistent format. This allows the DDI Agent to reason about your network using a universal language, regardless of the underlying hardware or software.
Sources: README.md:29-33, backend/app/agents/ddi/agent.py:13-15
Deployment Options
Engineers have two primary ways to deploy the platform depending on the size of the team and the required reliability.
| Option | Ideal For | Key Characteristics |
|---|---|---|
| Docker Compose | Labs & Small Teams | Runs on a single server. Easy to set up with a single command. |
| Kubernetes (Helm) | Production | Multi-node setup. High availability ensures the platform stays up even if one server fails. |
Sources: README.md:37-45, deploy/docker/README.md:3-8
Agent Routing and Specialists
The platform uses a "Master Architect" (the supervisor) to route your questions to the correct specialist. You can think of these specialists as specialized team members.
Specialist Team Members
- DDI Agent: Handles DNS and DHCP troubleshooting and drafts name/address changes.
- Troubleshooting Agent: Diagnoses routing (BGP/OSPF) and connectivity (ACL/Firewall) faults.
- Discovery Agent: Enumerates what exists on the network (inventory, LLDP/CDP neighbors).
- Configuration Agent: Analyzes configuration drift and compliance against baselines.
- Security Agent: Audits firewall policies for overly-permissive or shadowed rules.
- Automation Agent: The only member allowed to execute changes after a human has approved them.
Sources: backend/app/llm/prompts/init.py:220-275, backend/app/agents/ddi/agent.py:12-25
Routing Logic
When you send a message, the Master Architect decides which specialist is the best fit based on your goal.
The DDI Agent specifically handles requests related to names and addresses, while the Troubleshooting Agent handles "live" traffic faults.
Sources: backend/app/llm/prompts/init.py:280-350, backend/app/agents/ddi/agent.py:32-37
Change Approval Workflow
Safety is maintained by ensuring that no AI can touch the network directly. All modifications follow a rigorous lifecycle.
- Draft: The DDI Agent prepares the change (e.g., "Add A record web-01 -> 10.0.0.5").
- Pending Approval: The change is visible in the "Changes" dashboard.
- Approved: A second network engineer reviews and approves the request.
- Executing: The Automation Agent takes the approved plan and talks to the vendor API to apply it.
- Completed / Rolled Back: The change is verified. If it fails, the system attempts to restore the previous state.
Technical Implementation
DDI Tools
The DDI Agent has two tiers of tools. "Read" tools access the live data map, while "Write" tools trigger the change request process.
| Tool Category | Examples | Action |
|---|---|---|
| Read-Only | lookup_dns_records, scope_utilization | Returns normalized data to the AI. |
| State-Changing | add_dns_record, delete_dhcp_range | Creates a ChangeRequest in the database. |
Sources: backend/app/agents/ddi/agent.py:17-25, backend/tests/agents/ddi/test_ddi_agent.py:145-165
Data Redaction (Security)
To prevent accidental exposure of credentials stored in DNS records (like SNMP community strings in TXT records), the platform uses a redaction layer. Before the AI sees any data, it is scrubbed of sensitive patterns.
# The AI sees this...
# "host": "edge-1", "txt": "<<REDACTED:cisco_type89>>"
# ...Instead of the real secret
# "host": "edge-1", "txt": "config=$9$nhEmQVczB7dqsO$X.NN.5KTHc..."
Sources: backend/tests/agents/ddi/test_ddi_agent.py:210-220, backend/app/agents/ddi/agent.py:19-20
Conclusion
DDI Management provides a secure, auditable, and multi-vendor way to manage critical network naming and addressing services. By combining specialized AI agents with a strict human-approval workflow, the platform allows network teams to automate routine tasks while maintaining absolute control over the infrastructure.