The multi-cloud drift problem
If all your DNS lived on one provider, drift detection would be straightforward. Query the API, compare against your expected state, flag differences. Done.
But most organizations don't have that luxury. Internal domains sit on Windows DNS servers. Public-facing zones live on Route 53 or Cloudflare. A team spun up a project on GCP and has zones there. Maybe an acquisition brought Azure DNS into the mix. Each provider has its own console, its own API, its own audit log format, and its own set of people with write access.
Drift in this environment is harder to detect because there's no single place to look. You'd need to check Route 53 via the AWS CLI, Azure DNS via the az CLI, Cloudflare via their API, GCP via gcloud, and Windows DNS via PowerShell remoting — then somehow correlate all that into a unified view. Most teams don't bother. They check whatever provider is relevant to the current incident and hope the rest is fine.
Why multi-cloud makes drift worse
More consoles means more access points
Every provider console is another place someone can make an untracked change. A developer with AWS access modifies a Route 53 record. An IT admin tweaks something in the Windows DNS MMC. A contractor adds a TXT record directly in Cloudflare for a domain verification. Each of these creates drift, but you'd have to be checking all five providers simultaneously to catch them all.
Different audit log formats
AWS gives you CloudTrail events. Azure has Activity Log. Cloudflare has their audit log API. Windows DNS has the DNS Analytical Event Log (if you remembered to enable it). GCP has Cloud Audit Logs. Even if you're diligent about checking for unauthorized changes, correlating events across five different logging systems with different schemas, timestamps, and retention policies is painful enough that nobody does it consistently.
Split responsibility
In many organizations, different teams own different providers. The cloud team manages Route 53. The infrastructure team manages Windows DNS. Security manages Cloudflare. Nobody has a complete picture of all DNS across the organization. Drift can live in the gaps between teams for months.
Provider-specific behaviors
Each provider handles DNS differently in subtle ways. Route 53 has alias records that don't exist on other providers. Cloudflare proxies records by default and adds its own metadata. Windows DNS has dynamic updates from DHCP that create and remove records constantly. Azure DNS has record sets rather than individual records. Any drift detection approach needs to account for these differences rather than treating all providers identically.
What a multi-cloud drift detection approach looks like
A single source of truth
You need one place that says "this is what our DNS should look like across all providers." This is your baseline — the approved state that everything gets compared against. Without it, you're just comparing live state to... nothing. You can't detect drift if you haven't defined what "correct" means.
This source of truth needs to be provider-aware. It knows that app.example.com lives on Route 53, that internal.corp.local lives on Windows DNS, and that cdn.example.com lives on Cloudflare. When it checks for drift, it queries the correct provider for each zone.
Scheduled polling per provider
Each provider needs to be queried on a regular interval. The system connects using the appropriate method — AWS SDK for Route 53, REST API for Azure and Cloudflare, WinRM for Windows DNS, gcloud libraries for GCP — pulls the current zone state, and compares it to the expected state.
The interval matters. Too frequent and you're making unnecessary API calls (and potentially hitting rate limits on some providers). Too infrequent and drift lives undetected for too long. Every 5-10 minutes is a reasonable default for most organizations.
Noise filtering
Not all differences are meaningful drift. Windows DNS zones are full of dynamic records from DHCP that change constantly — these aren't drift, they're expected behavior. Similarly, some TXT records are ephemeral (ACME challenge records for Let's Encrypt, domain verification records that get cleaned up). Your drift detection needs to be smart enough to ignore expected noise and alert only on meaningful changes.
This usually means filtering by record type (ignore ephemeral TXT records matching certain patterns), by zone (don't drift-check the DHCP reverse-lookup zone), or by source (ignore changes made by known automation service accounts).
Unified alerting
When drift is detected on any provider, the alert needs to go to the same place — your team's Slack channel, a shared email, an incident management system. If Route 53 drift alerts go to the cloud team's channel and Windows DNS drift alerts go to the infra team's email, you still don't have a complete picture. Unified alerting means one team (or one on-call rotation) is responsible for all DNS drift, regardless of which provider it appeared on.
The hard part: correlating changes across providers
Some DNS operations involve multiple providers. Migrating a zone from Windows DNS to Route 53 means records appear on one provider and disappear from another — that's not drift, that's a planned migration. A CDN cutover might change a CNAME on Cloudflare while simultaneously updating an origin record on Route 53.
A naive drift detector would fire alerts for both sides of these operations. A good one understands that changes were approved as a set and checks the overall intended state, not each provider in isolation. This is where having your drift detection tightly integrated with your change management workflow matters — the system knows "these five records are being migrated from provider A to provider B" and won't flag intermediate states as drift.
Practical implementation
Here's what setting this up actually looks like:
- Import all zones. Connect every DNS provider and pull the current state of every zone you manage. This becomes your initial baseline.
- Route all changes through one workflow. Every DNS change — regardless of which provider it targets — goes through the same submission and approval process. This ensures your source of truth stays current.
- Enable drift checks per provider. Configure the polling interval and connection credentials for each provider. Start with a longer interval (15 minutes) and tighten it as you tune noise filtering.
- Tune noise filters. After the first week, you'll see which "drift" is actually expected behavior (DHCP dynamics, Let's Encrypt challenges, etc.). Exclude those patterns so alerts are actionable.
- Lock down direct access. Once you trust the workflow, start removing write access to provider consoles. Make the change management system the only path to modify production DNS. This prevents drift at the source rather than just detecting it after the fact.
What this gives you
A team running drift detection across all their providers can answer questions that multi-cloud teams normally can't:
- "Has anything changed on any of our DNS providers since yesterday?" — answered in seconds, not hours of digging through five different audit logs.
- "Are all our DNS records consistent with what we approved?" — a yes/no answer rather than a shrug and "probably."
- "If we got breached, would we notice an attacker modifying DNS records?" — yes, within minutes, regardless of which provider they targeted.
- "Can we prove to an auditor that every DNS change was authorized?" — your drift detection history shows that any unauthorized change was caught and remediated promptly.
The goal isn't zero drift — that's unrealistic in any environment with multiple providers and multiple teams. The goal is fast detection, clear visibility, and a process to remediate. Multi-cloud makes that harder, but it also makes it more important.