Securing DNS in Hybrid and Multicloud Environments

In a separate blog post, we outlined the importance of DNS security. Here, we are going to discuss the common challenges and considerations for achieving end-to-end secure DNS in hybrid and multicloud environments.  

The fragmentation problem

The biggest challenge that consistently shows up in conversations with large enterprises is fragmented DNS resolution across different environments. Without a unified DDI platform, this is basically unavoidable in a hybrid world. Different environments, whether we are comparing cloud vs. on-prem or even Azure vs. AWS, come with their own DNS architecture and overall strategy.

At the simplest level, hosting workloads outside of your managed DNS infrastructure means losing visibility. Even if you have a solid on-prem DDI presence, any DNS traffic within cloud platforms traverses separate infrastructure, requiring an extra layer of visibility and control. Cloud DNS resolution is commonly performed through cloud-native DNS service such as Amazon Route 53, Azure DNS, or Google Cloud DNS. Deploying these services in enterprise cloud environments provides a single point of management and can streamline visibility. 

However, cloud computing is notorious for offering developers flexibility, and this can apply to DNS as well. It may be more convenient for developers to manage DNS themselves by installing DNS services on a host under their complete oversight and control. Disparate strategies like this will lead to many inconsistencies and can undermine security and visibility.

The logging gap nobody talks about

Even basic DNS visibility is often missing in cloud environments, and the reason is simple: logging isn't on by default. 

In AWS, Route 53 query logging has to be explicitly enabled and configured to send logs to CloudWatch; in Azure, DNS diagnostic logs require the customer to opt in through Azure Monitor. Google Cloud DNS is the same story. These are not difficult configurations, but they are easy to miss. DNS is foundational to modern infrastructure, but that may lead to it being overlooked and not given proper attention until something goes wrong. By that point, the audit trail you need no longer exists. 

No unified view across clouds

Even when logging is enabled, each cloud provider has its own approach to delivering DNS services: different resolution models, log formats and query routing behavior. So not only are there different dashboards to actually view each of these services, but you also have to understand the inner workings of each.

When an incident does occur, investigations require pivoting between platforms, aligning data that wasn't designed to talk to each other, and normalizing formats that don't match up. Every extra step slows down investigations and creates gaps.

The service availability risk

It's important to understand the massive impact that a DNS failure can have on everyday operations, and how far that disruption can reach across your infrastructure. One mistake or missed risk identification can cause an entire network and any services or applications running on the associated workloads to fail. 

Here is a prime example:

In October 2025, AWS experienced a major outage in its US-EAST-1 region that lasted over 15 hours. While only one region was affected, this is the largest, most used, and often the default region for services in AWS. And when this region went down, so did any service relying on it, including widely used services such as Slack, Zoom, Netflix, Snapchat, Signal, and more. And guess what the source of the outage was… DNS!

AWS's post-incident report identified a latent race condition in DynamoDB's DNS management system as the root cause of this outage, leading to endpoint resolution failures for the service. Customers experienced DynamoDB API errors, causing any services they run on DynamoDB, as well as any AWS-provided services that also rely on DynamoDB to be unreachable. 

While most enterprises wouldn't have as wide a blast radius in these circumstances compared to a hyperscaler like AWS, it is a demonstration of the impact that a DNS failure can have on an entire network; it's a domino effect. 

Ephemeral resources and dangling DNS

The ephemeral nature of cloud resources heightens existing DNS risks in on-prem environments. On one hand, IP address management becomes much more difficult. Addresses are dynamically assigned, so without any manual configuration tying a static IP to a resource, the address will constantly recycle. This becomes a real problem when trying to identify which IP belongs to which workload.  

Another consequence of ephemeral resources is the creation of dangling DNS records. When you spin up a cloud resource, point a subdomain at it, then deprovision the resource without cleaning up the DNS record, that subdomain is now pointing at nothing you own. An attacker can claim the abandoned resource and serve malicious content directly under your domain. This is called a subdomain takeover. Your users see your subdomain, but the content belongs to the attacker.

To put this issue into perspective, SentinelOne released some eye-opening data specifically around this problem, alerting clients to more than 1250 instances of subdomain takeover risk from deprovisioned cloud resources in a single year. In a research exercise, security teams took control of 150 abandoned Amazon S3 buckets that were still referenced by subdomains from government agencies and Fortune 500 companies and observed over 8 million live requests hit those compromised resources within four months. That's not a theoretical risk; that's real traffic hitting infrastructure that organizations didn't realize they'd lost control of.

This is why it is so important to keep a current inventory of DNS records tied to active cloud resources and to consistently monitor the environment for any changes from baseline or suspicious behavior. 

Attacks that get harder to catch in the cloud 

Other attack types are also taken to a new level when viewed in the cloud.

DNS tunneling works by hiding non-DNS traffic inside DNS queries and responses. Attackers may use this to send malware or to exfiltrate data, but it is essentially a hidden communication channel that bypasses security controls. DNS tunneling is one of the most common DNS attacks, but it tends to be more effective in cloud environments because it is hidden even deeper behind the enormous volume of legitimate DNS traffic. This makes it very hard to find malicious payloads without proper detection capabilities. 

DNS hijacking in on-prem environments typically requires an attacker to compromise individual workstations or servers and modify local DNS settings from within. That's still a valid attack path in cloud environments, but cloud architectures introduce entry points that are often more powerful and more exposed. If an attacker gains access to the IAM credentials controlling your DNS zones in the cloud-native DNS service, they don't need to touch a single endpoint. They can quietly reconfigure your DNS at the source and redirect traffic wherever they choose. 

The common thread across all of these challenges is visibility. Knowing what's in your environment, what it's doing, and what's talking to what. But visibility alone isn't enough. Attack methods are becoming more sophisticated and harder to detect manually, which means the monitoring tools that watch your DNS and cloud posture need to be just as smart. Without AI-powered detection built into that layer, most of these incidents won't be caught until it's too late.

So what do you do about it?

There really is no single right answer, and you don't need to do a full rip-and-replace to make meaningful progress.

The options generally fall into three approaches: extend your existing DDI platform into cloud environments to maintain centralized visibility and policy control, run fully on cloud-native DNS controls, or take a hybrid approach that uses cloud-native tools where they make sense and connects back to a centralized management layer for visibility and consistency.

AWS and Azure both offer DNS security controls native to their platforms: Route 53 Resolver, DNS Firewall and Azure Private Resolver with FQDN filtering. For organizations operating entirely within a single cloud, those tools cover the basics. But "the basics" is the ceiling, not the floor.

The gap shows up the moment you're operating across environments. Cloud-native DNS security is siloed by design. It sees what happens inside its own platform and stops there. For hybrid and multicloud environments, that means you're back to the same fragmented visibility problem.

Infoblox approaches the problem differently. Rather than securing DNS per-cloud, it operates as a unified layer across on-prem and cloud environments simultaneously, with predictive threat intelligence rather than reactive. Their Threat Defense platform identifies threat actor infrastructure (domains, IPs, patterns) before those indicators appear in an attack. 

Each deployment option has trade-offs in visibility, operational complexity, cost, and how well it integrates with what you already have. That decision is worth a conversation, and it starts with understanding where your current gaps actually are.