DDI Observability Metrics: Assess DNS and DHCP Availability

A Green Server Does Not Prove the Service Is Healthy

DDI observability metrics matter because an appliance can look healthy while the service behind it is already degrading. A DNS server may answer a ping while resolution slows. A DHCP service may be running while clients struggle to obtain addresses.

For a NOC, availability is not the same as server reachability. The real question is whether DNS and DHCP are delivering the expected service to clients, and whether the team can spot a change before users become the monitoring system.

Key Takeaways:

• Reachability is not availability. A server can be online while DNS resolution or DHCP allocation is degraded.
• Measure service outcomes first. Client-facing metrics like transaction success and response time highlight when performance shifts, while correlating multiple supporting metrics provides the context needed to pinpoint the cause. 
• Use baselines, not isolated numbers. A change from normal behavior can expose emerging problems before a static threshold is crossed.

What Does DNS and DHCP Availability Really Mean?

Availability starts with the service delivered to the client.

For DNS, ask whether queries receive the expected responses and whether those responses arrive within the expected time for that service and environment. A resolver can remain reachable while resolution slows or SERVFAIL responses increase. 

For DHCP, ask whether clients can successfully obtain or renew an address.

That distinction matters. CPU, memory, query volume, lease capacity, process state, and failover health are valuable diagnostic signals, but they do not prove availability by themselves. They help explain why client service is changing. 

The NOC Availability Scorecard: DDI Observability Metrics to Track

A useful scorecard starts with what clients experience, then adds the evidence needed to explain performance, capacity, and risk.

1. DNS Performance and Service Quality

Resolution success rate and response latency are the primary indicators of client-facing DNS service quality. Query volume, cache behavior, packet size, and response-code patterns provide the operational context needed to understand performance changes.

Metric	What it tells you	Applies to	Watch for	First check
Query volume	Total DNS traffic load handled by the service	Global, server, or view	Unexpected spike or drop	Top source IPs, queried domains (FQDNs), and query types (QTYPEs)
Recursion latency	Time taken to complete external recursive resolution	Recursive DNS	Sustained increase	Upstream forwarders, network path/RTT, and root/TLD server responsiveness
Cache hit ratio	Percentage of queries answered directly from local cache	Recursive DNS	Unexpected decline	Query mix changes, low TTLs, or cache-busting traffic patterns
DNS packet size	Request/response payload distribution and EDNS0 buffer usage	Recursive and Authoritative DNS	Spikes in large payloads or truncated (TC bit) responses	DNS Amplification attempts, DNS tunneling, DNSSEC expansion, or Path MTU / UDP fragment drops
Response codes	Distribution of successful vs. failed query outcomes	Global, server, or view	SERVFAIL rise, unusual NXDOMAIN spike, or REFUSED changes	Determine whether changes reflect expected negative responses, genuine resolution failures, or configuration/policy issues (e.g., missing records, DNSSEC validation, delegation errors, or RPZ/Guardian rules)

Recursion latency and cache hit ratio apply mainly to recursive DNS. NXDOMAIN is often a valid response, so changes should be investigated in context rather than treated automatically as service outages or failures.

2. DHCP Service and Capacity

For DHCP, the first question is simple: are clients successfully obtaining IP addresses and network parameters?

In DHCPv4, monitoring the four-step DORA sequence (DISCOVER, OFFER, REQUEST, ACK) verifies that allocation is completing. Unanswered DISCOVERs, dropped REQUESTs, or spikes in DHCPNAK (rejected requests) and DHCPDECLINE (IP conflicts) pinpoint client connectivity issues.

Scope utilization, lease depletion rates, and HA failover synchronization status provide the operational context needed to prevent scope exhaustion before clients are impacted.

In DHCPv6, the same operational principles apply using the SARR sequence (SOLICIT, ADVERTISE, REQUEST, REPLY) to confirm successful allocation, prefix capacity, and service redundancy.

3. Infrastructure and Resilience

When service performance changes, infrastructure metrics help explain why.

CPU and memory pressure, disk or network throughput issues, stopped DNS or DHCP processes, and degraded HA or replication states can all narrow the investigation. These signals are most useful when correlated with a change in client-facing service.

4. Client and Anomaly Context

Client-level context answers another critical question: is the problem widespread or isolated?

Source IP, query volume, recursion time, errors, and queried FQDNs can show whether a specific client, application, workload, appliance, or site is driving the change. That distinction can quickly narrow where the NOC should investigate next. 

Turn Metrics Into Early Warning Signals

A threshold without context can be misleading.

Traffic that is routine for a core resolver may be abnormal for a branch appliance. A DHCP scope can also appear healthy at a single point in time while its rate of consumption shows that available capacity is disappearing quickly.

Useful alerts combine the current state with the normal baseline, historical trend, rate of change, site criticality, and operational risk. This context helps teams identify gradual deviations from normal service behavior before they become user-impacting problems. 

From Warning Signal to Root Cause

Once current behavior deviates meaningfully from the expected baseline, the next question is what is causing it. A single metric rarely provides the answer. Correlating several signals helps show how significant the change is and where to investigate next.

Consider an increase in NXDOMAIN responses. On its own, that does not prove there is a service problem or an attack. The first step is to compare the change with normal DNS behavior over time. If NXDOMAIN responses are rising while recursion time is also increasing, the combination is a stronger signal that the change deserves investigation.

The next step is to test likely explanations against other metrics. If query volume remains relatively stable, a broad traffic surge becomes a less likely cause. A decline in cache hit ratio or an unusual change in DNS packet size may also suggest that the pattern of DNS requests has changed.

From there, the investigation can move from service-level indicators to the DNS activity behind them. DDI Observability Center identifies the change in service behavior and when it began. DNS Intelligence Center adds domain-level and threat intelligence context, helping determine whether unusual activity is concentrated around specific domains and whether those domains carry known risk indicators. DNS Guardian analytics can then confirm whether the same pattern is visible at the live DNS service level.

No single dashboard provides the answer on its own. The value comes from correlating historical behavior, DNS performance, domain activity, and service analytics to progressively narrow the investigation.

How DDI Observability Center Helps

DDI Observability Center gives NOC teams the starting point for that investigation: comparing current DNS metrics with historical baselines, identifying when the change began, and where deeper analysis is needed.

It brings DNS service performance, DDI infrastructure health and performance, historical trends, and client-level DNS activity into a consolidated operational view. When an anomaly needs deeper investigation, teams can correlate those observations with DNS Intelligence Center for domain-level threat intelligence and risk context, and DNS Guardian for real-time DNS transaction, behavioral security insights, and logs.

Instead of piecing together isolated signals, the NOC can progressively narrow an issue to the affected domain, appliance, site, client, or workload. Network and security teams can also feed these metrics into their SIEM, SOAR, or NAC systems through APIs to accelerate root cause analysis and support broader security investigations. This helps teams focus root-cause analysis faster, detect degradation earlier, and build stronger evidence of service health over time. 

Make Availability Something You Can Demonstrate

The goal is not to collect more metrics. It is to know whether DNS and DHCP are delivering the service users depend on, spot when that changes, and have enough context to investigate quickly.

With the right DDI observability metrics and historical context, NOC teams can move from assumed uptime to demonstrated service health and performance.