As enterprise networks expand across data centers and multiple clouds, the services that connect users and applications become harder to govern. DNS, DHCP, and IP address management, collectively known as DDI, sit at the center of that challenge. Hema Latha Kamarthi, a Staff DDI Engineer, focuses on making these foundational services reliable, visible, and accountable across the enterprise.
Her expertise spans infrastructure modernization, DDI architecture, and multi-cloud networking. Her experience includes a DNS and DHCP migration in an environment processing approximately 400,000 DNS queries per second. That scale puts engineering judgment under pressure: changes must preserve application dependencies, and recovery plans must work when infrastructure becomes unavailable.
Kamarthi’s approach connects that operational discipline with cybersecurity. Secure DNS resolution and accurate address records help organizations understand how workloads communicate and where policy can be enforced. As enterprises adopt Zero Trust, she argues that DDI deserves a deliberate place in their security architecture.
DDI as strategic assets
Many enterprises still treat DNS and IP address management as administrative utilities. That approach overlooks the visibility these services provide into connected devices and application behavior. “The greatest danger is a false sense of security,” Kamarthi notes. Keeping a service available does not establish that an organization understands who is using it or whether its records remain accurate.
Market reports from Mordor Intelligence and Dataintelo examine demand for integrated DDI solutions. The DDI Directions research report identifies operational challenges involving inconsistent IPAM capabilities and gaps in lease visibility. For Kamarthi, modernization should address those gaps through dependable inventory, clear ownership, and processes that keep records aligned with deployed infrastructure.
Fragmented records slow investigations when teams need to identify which workload held an address and who owns the response. “Investing in DDI visibility, accurate ownership records, and clear accountability helps teams answer those questions before a crisis—and respond faster when one occurs,” Kamarthi states. That context helps teams contain problems without unnecessary disruption.
Zero Trust DNS enforcement
DNS can support Zero Trust when resolution policy is tied to enforceable controls. “The transformation starts with understanding the resolution paths applications actually use,” Kamarthi explains. Microsoft’s Zero Trust DNS documentation illustrates one approach: trusted encrypted DNS combined with endpoint restrictions on outbound connections. Encryption protects the exchange; the endpoint controls enforce connection policy.
Discussions of DNS security in Zero Trust and enterprise DNS controls reflect the attention these services now receive. Implementing them requires identifying approved resolvers, documenting exceptions, and understanding where applications can use alternative resolution paths. Policy must remain observable and consistent across the environments it is intended to cover.
Availability remains part of the design. Resolver failover should preserve the intended security controls, and recovery procedures should account for policy exceptions. “Successful name resolution does not grant permission to access a resource,” Kamarthi notes. DNS controls must work alongside identity verification and application authorization; resolver placement alone cannot provide either.
Visibility across hybrid DNS
Hybrid networks distribute DNS activity across enterprise forwarders and cloud resolution services. That makes a complete view of application behavior difficult to obtain from a traditional perimeter alone. “My focus is on connecting a DNS event to the workload that generated it and understanding how the query reached its destination,” Kamarthi states.
Reconstructing that path requires correlating resolver logs with workload inventory and address history. Zscaler’s discussion of DNS threat detection describes examining domain patterns and query distribution for signs of suspicious activity. These signals can support investigations into tunneling or command-and-control behavior, but require context before teams conclude that a workload is compromised.
“Perimeter monitoring alone can miss activity handled within cloud networks or outside the traditional data-center boundary,” Kamarthi notes. Bringing evidence together through security data integrations helps investigators follow activity across systems. The value comes from knowing what the logs cover, which client generated the request, and where visibility remains incomplete.
Adapting Active Directory
DNS modernization must accommodate the directory services and applications that already depend on it. “In enterprise migration scenarios, a central consideration is determining which DNS responsibilities belong with Active Directory and which require broader enterprise integration,” Kamarthi explains. That distinction keeps the migration focused on service requirements and operational ownership.
Resources on modernizing DNS architecture and unified DDI platforms describe approaches to managing distributed network services. The engineering task is to validate the destination platform’s capabilities, preserve application behavior, and establish a tested recovery path before cutover. Centralized management delivers value when those dependencies remain supported.
Modernizing enterprise DNS can preserve Active Directory while moving DNS hosting and management to a dedicated platform. “My recommendation is to retain Active Directory for identity services while migrating DNS to an enterprise DDI platform that supports AD’s service discovery and secure dynamic update requirements,” Kamarthi states. With these dependencies validated, organizations can integrate cloud DNS, automate record lifecycle management, and establish consistent security monitoring across their environments.
Automation and security posture
Automating network changes shifts engineering effort toward validation and exception handling. Configuration as code for DDI makes routine changes repeatable and reviewable. “Network discovery and certificate lifecycle automation can address a recurring operational risk: essential controls depending on someone remembering to perform the next step,” Kamarthi notes.
The same discipline extends to configuration assurance. Research on automated endpoint compliance in Linux environments examines a related operational problem, while identity and configuration monitoring can help expose excessive privileges and drift. Within DDI, validation should connect an approved request to the resulting allocation, DNS records, and recorded owner.
“Automation itself needs restricted permissions, protected credentials, and recovery procedures,” Kamarthi explains. A dependable workflow verifies the result and records partial failures so operators can recover safely. If an address is allocated but its DNS update fails, the request needs further action before it can be treated as complete.
Separating DNS namespaces
Separating public and internal DNS requires examining the infrastructure behind each namespace. Shared network paths, capacity, or administrative dependencies can allow an external disruption to affect internal services. “When advising leadership, I frame this as a question of exposure and containment,” Kamarthi states. The design must reflect which dependencies can fail together.
Protective DNS can help block access to malicious destinations. Resilience against service disruption also requires sufficient capacity and tested recovery behavior. A separate namespace, by itself, does not isolate the infrastructure serving it; engineers need to verify how the surviving systems behave under load.
“The executive decision is how much disruption the organization can tolerate and which services must remain available,” Kamarthi explains. That decision should guide service placement, failure testing, and recovery priorities. Demonstrating that critical applications remain usable during a failure gives leadership evidence on which to base those choices.
Bridging NetOps and SecOps
Network and security teams depend on much of the same infrastructure data, yet separate tools and ownership can leave investigations fragmented. DNS modernization offers an opportunity to improve that coordination. “I recommend making DDI a shared operational foundation, with clear accountability throughout the lifecycle of each connected service,” Kamarthi notes.
A shared view should connect an address to its workload, responsible team, and relevant history. It also needs an operating agreement: who investigates suspicious activity, who approves a policy change, and who verifies the outcome. Centralizing data helps only when teams can trust its accuracy and act on it.
“Both teams also need trustworthy context,” Kamarthi states. An IP address may have been reassigned since an event occurred, so current inventory alone can misidentify the affected workload. Preserving ownership history and reviewing incidents together helps teams improve provisioning, record cleanup, and response decisions.
Instilling Zero Trust
Security principles become effective through the decisions engineers make during daily operations. “Building a global operations team requires a shared definition of successful service restoration,” Kamarthi explains. Restoring connectivity should include confirming that the intended security controls remain in place.
Engineers need to understand application dependencies before approving narrowly scoped access changes. Zero Trust assessments also depend on evidence that explains how controls operate. Recording the justification, owner, and review conditions for an exception helps prevent a temporary workaround from becoming an unmanaged dependency.
“For a global team, handoffs must preserve the reasoning behind decisions: what changed, why, which risks remain, and who owns the next action,” Kamarthi states. Clear handoffs allow engineers in another time zone to continue the work with the context needed to make sound decisions.
Measuring engineering improvements
Modernization needs evidence of sustained operational benefit. “I would look for evidence that an improvement continues to work under real operating conditions and can be maintained by others,” Kamarthi notes. Change records should connect approval, execution, and verification; the NetClaw project’s documented workflow provides one implementation example of that process.
Useful measures include DNS response latency and failure rates, recovery time during tests, and the time needed to identify a workload’s owner. Integrating protective DNS with endpoint enforcement also requires checking how policy changes affect legitimate applications. Engineers should document the benefits alongside the dependencies and limits of each design.
“A strong engineering standard emphasizes improvements that can be explained, tested, and sustained, with clear evidence of their benefits and limits,” Kamarthi states. Documentation and repeatable validation help the next operator maintain those improvements as workloads and infrastructure change.
For Kamarthi, enterprise modernization depends on making foundational services easier to understand and govern. Accurate DDI data gives teams a basis for decisions, controlled automation makes changes repeatable, and tested recovery protects service continuity. Her emphasis is on infrastructure that engineers can operate with confidence and security teams can use as a dependable source of context.