Notifications
Clear all
Topic starter
23/06/2026 7:13 pm
TL;DR: DNS traffic now carries both availability and security risk as encrypted resolution, blocking strategies, and misconfiguration can alter visibility and performance, according to DigiCert. For identity teams, the lesson is that network-level control and identity governance now intersect wherever DNS becomes a policy enforcement point.
NHIMG editorial — based on content published by DigiCert: What You Need to Know About DNS Traffic
By the numbers:
- In June 2025, UltraDNS processed 136 billion DNS queries daily.
Questions worth separating out
Q: How should security teams govern encrypted DNS without losing visibility?
A: Security teams should define where encrypted DNS is allowed, which resolvers are trusted, and what telemetry remains available when queries are hidden inside HTTPS or TLS.
Q: When does DNS blocking become a resilience problem instead of a control?
A: DNS blocking becomes a resilience problem when it breaks legitimate resolution paths, forces users to bypass approved resolvers, or causes applications to fail because of misconfiguration.
Q: What do organisations get wrong about DNS load balancing?
A: They often treat load balancing as a routing optimisation only, then miss its role in service continuity.
Practitioner guidance
- Map encrypted DNS policy by environment Separate corporate endpoints, managed workloads, and guest networks so each zone has an explicit rule for DoH and DoT.
- Review resolver dependencies before changing blocking rules Test whether internal applications, security tools, and remote users depend on specific resolvers before enforcing inspection or NXDOMAIN-based blocking.
- Tune TTLs and failover paths together Use caching to reduce lookup load, but verify that TTL values do not slow recovery when authoritative records change.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step DNS traffic management guidance for performance, availability, and policy enforcement.
- Practical comparisons of DoH, DoT, caching, and DNS load balancing in operational environments.
- Examples of how resolver choices affect latency, inspection, and control in mixed networks.
- Troubleshooting detail for misconfiguration, blocking, and legacy compatibility scenarios.
👉 Read DigiCert's guide to DNS traffic, encrypted resolution, and blocking →
DNS traffic, DoH, and DoT: what IAM teams should watch?
Explore further
25/06/2026 3:07 am
DNS visibility is now a governance boundary, not just a network setting. Once resolution moves into encrypted channels like DoH and DoT, teams lose the assumption that DNS queries are always inspectable in transit. That affects monitoring, incident response, and policy enforcement across user, workload, and service identities. The practical conclusion is that DNS control must be designed as part of identity and access governance, not left to network defaults.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do teams know if DNS caching is helping rather than hiding problems?
A: DNS caching is helping when it reduces repeated lookups without delaying record updates or masking resolver failure. The key signals are lower query volume, stable latency, and fast propagation when records change. If outages persist after cache tuning, the problem is likely upstream resolver design rather than cache efficiency.
👉 Read our full editorial: DNS traffic management and encrypted resolution are reshaping security
