DNS traffic management and encrypted resolution are reshaping security

At a glance

What this is: This is a DNS traffic management explainer that argues encrypted resolution, blocking, and load balancing affect both security visibility and service reliability.

Why it matters: It matters to IAM and security practitioners because DNS policy decisions increasingly shape access, inspection, and control boundaries for users, workloads, and managed services.

By the numbers:

• In June 2025, UltraDNS processed 136 billion DNS queries daily.

👉 Read DigiCert's guide to DNS traffic, encrypted resolution, and blocking

Context

DNS traffic is the request-and-response path that translates a domain name into an IP address. In practice, that means the DNS layer now sits inside broader identity and access decisions because it determines which resolver, which policy, and which destination a user or workload reaches first.

The article shows that DNS is no longer a simple infrastructure utility. Encrypted DNS, blocking, caching, and load balancing all change what defenders can see and control, which makes DNS a governance issue for NHI, agentic AI, and human identity programmes that depend on reliable name resolution.

For security teams, the difficult part is not whether DNS should be protected but where protection ends and loss of visibility begins. That balance is especially important when organisations depend on internal resolvers, inspection controls, or policy enforcement tied to network identity and access boundaries.

Key questions

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. The right model is policy by environment, not a single enterprise-wide rule. If internal inspection matters, force managed resolvers and log their use consistently.

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. That usually happens when teams block first and test later. The better approach is to validate business-critical domains before enforcement changes go live.

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. DNS load balancing also affects failover, regional performance, and recovery from partial outages. Teams should verify health checks, TTL behaviour, and endpoint capacity together so one bad node does not become a broad outage.

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.

Technical breakdown

Why DNS over HTTPS and DNS over TLS change control boundaries

DNS over HTTPS, or DoH, sends queries inside standard HTTPS traffic on port 443, while DNS over TLS, or DoT, uses TLS on port 853. Both encrypt the query content, which reduces interception risk but also hides resolution activity from tools that were built for plaintext inspection. That matters because DNS is often treated as an observable control plane. Once the query is encrypted, the resolver relationship, visibility model, and enforcement path change. DoH also blends with normal web traffic, which can make policy enforcement harder than with a dedicated DNS port.

Practical implication: decide where encrypted DNS is permitted, then align resolver policy and inspection tooling with that decision.

How DNS blocking works at the resolver and network layers

DNS blocking can happen by returning NXDOMAIN, filtering at firewalls, or using deep packet inspection to detect encrypted resolution attempts. The technical trade-off is that the more aggressively a network blocks or inspects DNS, the more it risks breaking legitimate lookups or creating blind spots if users switch to external resolvers. This is why DNS blocking is not just a content-control issue. It becomes an enforcement problem, because the resolver is effectively being used to steer user and application behaviour.

Practical implication: map which blocking method applies to which policy goal before allowing it to affect production resolution paths.

Why DNS load balancing and caching affect resilience and latency

DNS load balancing spreads queries across multiple endpoints using round robin, geolocation, weighting, or failover. Caching and TTL tuning reduce repeat lookups and lower resolver load, which can improve responsiveness during peak traffic. The point is not only faster page loads. DNS also shapes availability because a badly tuned resolver or overloaded authoritative service can create an outage even when the application itself is healthy. In large environments, DNS performance is part of service continuity, not an afterthought.

Practical implication: review TTLs, failover rules, and resolver capacity together instead of treating them as separate operational tasks.

NHI Mgmt Group analysis

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.

Encrypted DNS creates a policy tension between privacy and enforceability. The article is right to separate user privacy from operational control, but the deeper issue is that organisations often rely on DNS observation as a security signal. When that signal disappears, defenders must choose between restoring visibility through managed resolvers or accepting a smaller enforcement surface. The field should treat this as a control-design decision, not a protocol preference.

DNS reliability is now part of identity service resilience. A resolver failure, overloaded authoritative service, or misconfigured blocking rule can interrupt access just as effectively as an authentication fault. That makes DNS uptime relevant to IAM, PAM, and NHI programmes that depend on consistent reachability to directories, APIs, and control planes. Practitioners should treat DNS health as an upstream dependency of access availability.

DNS load balancing is a blast-radius control for access paths. The concept is useful because it limits the impact of a single resolver or endpoint failure, especially in globally distributed environments. That does not make DNS a substitute for identity controls, but it does mean service continuity depends on how evenly and intelligently resolution is distributed. Teams should evaluate DNS as part of resilience architecture, not just routing optimization.

From our research:

• 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.
• For a broader identity lens, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how access governance is evolving across machine and agentic systems.

What this signals

DNS policy is becoming an upstream identity control. When resolution is forced through trusted resolvers, security teams gain a leverage point over destinations that users, workloads, and managed services can reach. That means DNS decisions now affect the effective blast radius of identity sessions, especially where internal name resolution is tied to access to private services.

With 44% of developers following secrets-management best practices, per The State of Secrets in AppSec, the broader control problem is familiar: organisations often assume a policy exists because a control exists. DNS governance works the same way. If inspection, blocking, and resolver trust are not tested together, visibility gaps appear exactly where teams expect enforcement.

Resolver trust boundary: the point where the network decides which DNS authority is allowed to answer. Teams should define that boundary explicitly, then validate it against remote access, browser behaviour, and workload traffic so encrypted resolution does not create shadow routing paths.

For practitioners

• 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. Then document which resolvers are trusted and which traffic paths are blocked or inspected.
• 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. A policy that improves visibility can still create outage risk if it breaks name resolution.
• 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. Pair failover-based routing with monitored health checks so a failed endpoint is removed before users notice impact.
• Treat DNS logs as an access signal Use DNS telemetry to detect unusual domain lookups, external resolver use, or spikes tied to suspicious activity. Correlate DNS events with identity logs so you can distinguish user behaviour from workload behaviour.

Key takeaways

• Encrypted DNS improves privacy but also weakens default inspection, so the control question is where visibility should be restored and by whom.
• DNS blocking, caching, and load balancing all affect resilience, which means resolver design belongs in security architecture reviews.
• Identity teams should treat DNS telemetry and trusted resolver policy as upstream controls that shape access, containment, and service continuity.

Key terms

• Encrypted Dns: DNS queries sent inside a protected transport such as HTTPS or TLS instead of plaintext. Encryption reduces interception and tampering, but it also reduces the visibility available to traditional monitoring tools. In practice, it shifts control from passive inspection toward resolver trust and policy enforcement.
• Resolver: A resolver is the service that receives a domain lookup and returns the matching IP address or other DNS record. It sits at a critical control point because it can shape what users and workloads can reach, what gets logged, and which traffic paths are trusted.
• Dns Load Balancing: DNS load balancing distributes queries across multiple endpoints so a single server or region does not carry all traffic. It can improve availability, latency, and failover, but it also depends on correct TTL values, health checks, and routing logic to avoid masking failure conditions.
• Doh And Dot: DoH and DoT are encrypted DNS transport methods. DoH hides DNS inside regular HTTPS traffic, while DoT uses a dedicated TLS channel for queries. Both improve privacy, but each changes how defenders inspect, block, and govern resolution traffic.

Deepen your knowledge

NHI governance, machine identity security, and workload identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.

This post draws on content published by DigiCert: What You Need to Know About DNS Traffic. Read the original.