DNS is one of those things that just works – until it doesn’t. And when it doesn’t, nothing else works either.
Every cloud workload, every API call, every email message depends on DNS. Yet most cloud providers treat DNS as a commodity checkbox rather than a security-critical layer. That gap between “it works” and “it’s secure” is where enterprise risk lives.
The DNS Blind Spot
DNS is involved in over 90% of malware communications. Attackers use it for command-and-control channels, data exfiltration, and domain hijacking because DNS traffic is rarely inspected and almost always allowed through firewalls.
The average internet user encountered 66 DNS threats per day in 2025, up from 29 in 2024 – a 127% increase. DNS tunneling for command-and-control now outpaces brute-force and flood-based attacks. And the vulnerabilities keep coming:
- KeyTrap (CVE-2023-50387) – A single malicious DNS packet could exhaust a DNSSEC-validating resolver’s CPU for hours, causing denial of service. Disclosed in February 2024, it affected every major resolver: BIND 9, Unbound, PowerDNS Recursor, Knot, dnsmasq, and Windows Server DNS. Patches are available, but organizations running unpatched resolvers remain vulnerable. The PoC exploit is public.
- Sitting Ducks – Infoblox identified 800,000 domains vulnerable to hijacking through lame delegations, with 70,000 already confirmed hijacked. Attackers claim authority over zones that legitimate owners have abandoned at their DNS provider. Over a dozen threat actor groups – primarily Russian – are cooperating to exploit this at scale. Major brands including McDonald’s and Paramount Global have been affected.
- DNSBomb (CVE-2024-33655) – A pulsing denial-of-service technique presented at IEEE S&P 2024 that abuses DNS query aggregation to amplify traffic bursts by up to 20,000x. All 10 mainstream DNS software implementations tested were vulnerable.
- BIND 9 cache poisoning (October 2025) – CVE-2025-40778 and CVE-2025-40780 allow attackers to poison DNS caches by exploiting a weakness in BIND’s PRNG, predicting source ports and query IDs to inject malicious responses.
These are not theoretical. They are actively exploited. And they expose a fundamental problem: most organizations have no visibility into their DNS infrastructure’s security posture.
What Enterprise DNS Security Actually Requires
Securing DNS is not a single feature. It is a stack of controls that work together. Here is what each layer looks like in practice.
DNSSEC: Sign Your Zones, Validate Your Responses
DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with in transit. Without it, DNS responses are unsigned plaintext that any on-path attacker can modify.
Global adoption remains low. Only 36% of DNS queries use DNSSEC-validating resolvers (APNIC Labs, 2025). Just 5% of .com domains and 4% of .net domains are signed at the second level. APNIC published new guidance in February 2026 calling for industry best practices around DNSSEC automation to reduce the operational burden that has stalled adoption.
What matters in implementation: algorithm choice. Older algorithms like RSA-SHA1 are deprecated. Modern deployments should use ECDSA P-256 (Algorithm 13, ECDSAP256SHA256), which provides strong security with smaller key sizes and faster signature verification. NSEC3 should use zero additional iterations per current best practice, as extra iterations add computational cost without meaningful security benefit.
Key lifecycle matters too. Zone Signing Keys (ZSK) should rotate regularly, and Key Signing Key (KSK) rollover should follow RFC 7344 using CDS/CDNSKEY records for automated DS updates at the parent zone.
Authenticated Zone Transfers
Zone transfers (AXFR/IXFR) replicate DNS data between primary and secondary nameservers. Without authentication, anyone who can reach your nameserver on port 53 can request a full copy of your zone – a complete inventory of your infrastructure.
TSIG (Transaction Signature) authentication solves this by requiring a shared secret to authorize transfers. The algorithm matters here too. HMAC-SHA-256 is the right choice – it is FIPS-approved, widely supported, and avoids the weaknesses of HMAC-MD5.
Critically, most major cloud DNS providers do not support zone transfers at all. AWS Route 53, Azure DNS, and Google Cloud DNS all lock you into their platform with no standard mechanism to replicate zones to external nameservers.
Modern Record Types
DNS is not just A and AAAA records anymore. Two relatively new record types meaningfully improve security:
- SVCB/HTTPS records (RFC 9460/9461) enable clients to discover HTTP/3, Encrypted Client Hello (ECH), and alternative endpoints in a single DNS lookup. This reduces connection latency and enables privacy features that depend on DNS-level signaling.
- CAA records control which Certificate Authorities can issue certificates for your domain. Without CAA, any public CA can issue a certificate for your domain if an attacker can pass domain validation.
Audit Logging
Every DNS change should produce an immutable audit trail. Who created the zone, who added the record, when it was modified. In a multi-tenant environment, this is not optional – it is a control framework requirement. Logs should feed into a centralized system where they can be queried, alerted on, and retained according to your compliance needs.
FIPS-Validated Cryptography
For regulated industries – federal, financial, healthcare – it is not enough to use “strong crypto.” The cryptographic modules themselves must be validated. FIPS 140-3 validation (not just “compliance”) means the implementation has been tested by an accredited lab and certified by NIST’s Cryptographic Module Validation Program. This applies to every cryptographic operation: DNSSEC signing, TSIG authentication, and TLS for API access.
Multi-Tenant Isolation
In a shared cloud, DNS must enforce strict tenant boundaries. Per-project quotas prevent noisy-neighbor abuse. Role-based access control (admin, member, reader) ensures that only authorized users can modify zones. Zone sharing across projects should be explicit and auditable, not implicit.
What Most Cloud Providers Get Wrong
The major hyperscalers built DNS services optimized for scale and simplicity. That is fine for basic use cases, but it leaves gaps for enterprises that need real DNS security.
| Capability | AWS Route 53 | Azure DNS | Google Cloud DNS | Open Edge |
|---|---|---|---|---|
| DNSSEC signing | Yes | Yes (GA) | Yes | Yes (ECDSA P-256, auto) |
| Zone transfers (AXFR) | No | No | No | Yes, TSIG-authenticated |
| Secondary zones | No | No | No | Yes |
| SVCB/HTTPS records | Yes | No | No | Yes (RFC 9460/9461) |
| Catalog zones (RFC 9432) | No | No | No | Yes |
| TSIG authentication | No | No | No | Yes (HMAC-SHA-256) |
| BYO nameservers | No | No | No | Yes |
| Per-query pricing | $0.40/M queries | $0.40/M queries | $0.40/M queries | Zero |
| Per-zone pricing | $0.50/zone/mo | $0.50/zone/mo | $0.20/zone/mo | Zero |
| FIPS 140-3 validated crypto | Varies by service | Varies by service | No | Yes (CMVP #5115) |
The zone transfer gap is the most consequential. Without AXFR support, you cannot run secondary nameservers outside your cloud provider. You cannot maintain a warm standby with an independent DNS provider. You are locked in, and if your provider has an outage, your DNS goes down with it.
How Open Edge Approaches DNS Security
Open Edge runs DNS-as-a-Service via OpenStack Designate 21.0.0 backed by PowerDNS 4.x with a MariaDB backend. The service is deployed as 21 containers (7 per control node) across three control nodes, with three authoritative nameservers (ns1/ns2/ns3.us-east-1.open-edge.io) serving queries over both IPv4 and IPv6.
Here is what that looks like in practice:
- DNSSEC is automated. New zones are signed daily at 03:00 UTC via cron. ZSK rollover runs quarterly on keys older than 90 days. Algorithm 13 (ECDSAP256SHA256) with 256-bit P-256 keys, NSEC3 at zero iterations. KSK rollover uses RFC 7344 CDS/CDNSKEY. DS digest is SHA-256.
- Zone transfers use TSIG with HMAC-SHA-256 exclusively (HMAC-MD5 is explicitly prohibited). Full AXFR and incremental IXFR are supported. You can run your own secondary nameservers or replicate to a third-party DNS provider. This is the single largest gap between Open Edge and every major hyperscaler.
- 16 record types including SVCB and HTTPS records (RFC 9460/9461) for HTTP/3 and ECH support, plus CAA for certificate issuance control, SSHFP for SSH fingerprint verification, and catalog zones (RFC 9432) for automated zone provisioning across nameserver fleets.
- Reverse DNS with automatic PTR record creation for floating IPs, integrated directly with the Neutron network layer.
- Every API call is logged to Loki via oslo.messaging notifications. PowerDNS exports 70+ metrics via Prometheus for operational visibility. When someone asks “who changed that DNS record?” you have the answer in minutes.
- Per-tenant quotas (32 zones, 500 recordsets per zone, 20 records per recordset) and RBAC with admin/member/reader personas enforce multi-tenant isolation. Zone sharing across projects within the same organization is explicit and auditable.
- All cryptographic operations run on FIPS 140-3 validated modules (CMVP Certificate #5115, Ubuntu 24.04 LTS OpenSSL 3.x). Every DNSSEC signature, TSIG authentication, and API TLS connection uses FIPS-approved algorithms.
- Zero per-query and per-zone pricing. DNS is included in the platform. No metering surprises.
The dashboard provides full CRUD management for zones and recordsets, so your team does not need CLI access for routine DNS operations.
What We Do Not Do (And Why)
Transparency matters more than a features list. Here is what Open Edge does not currently offer for DNS:
- DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) – These are recursive resolver features that encrypt queries between end-user clients and their resolver. Open Edge provides authoritative DNS, which answers queries from other DNS servers, not from end-user browsers. DoH/DoT is the responsibility of your recursive resolver. Note that Firefox now enables DoH by default in the US and Canada (via Cloudflare), and Chrome auto-upgrades to DoH when the system resolver supports it. For enterprise environments, this can break internal DNS visibility and split-horizon configurations – something to manage at the endpoint policy level, not the authoritative nameserver.
- Protective DNS / DNS Firewall – Threat-intelligence-based query filtering is a recursive resolver function. CISA’s Protective DNS program has blocked nearly 700 million malicious connections for federal agencies since 2022, processing 3+ billion queries daily. In 2025, CISA expanded the program to non-federal critical infrastructure. We recommend pairing our authoritative DNS with a protective recursive resolver like CISA’s service (for eligible orgs), Cloudflare Gateway, or Cisco Umbrella.
- Health-check-based routing – Weighted, geographic, and failover routing based on health checks is not implemented. If you need this, a layer like Cloudflare or NS1 in front of your zones can provide it.
- Global anycast – We currently operate in a single region (Iron Mountain VA-1, us-east-1). Multi-region anycast is on the roadmap for Q3-Q4 2026 with our Portland expansion.
These are deliberate scope boundaries, not oversights. Authoritative DNS and recursive DNS serve different roles, and conflating them leads to muddled security architecture.
Gaps We Are Addressing
Two areas where we are actively improving:
- DNS Response Rate Limiting (RRL) – PowerDNS supports RRL natively, but it is not enabled by default in our deployment. This is a straightforward configuration change that we are rolling into our next maintenance cycle. RRL mitigates DNS amplification attacks by throttling identical responses to the same source.
- Multi-region anycast – A single-region DNS deployment is a single point of failure for latency-sensitive global workloads. Our Portland (us-west-1) expansion in Q3-Q4 2026 will enable anycast DNS across both regions.
Take Control of Your DNS Security
DNS security is not something you bolt on after the fact. It needs to be built into the platform from the infrastructure layer up – signed zones, authenticated transfers, audit logging, validated cryptography, and tenant isolation working together.
If your current provider charges you per query, locks you out of zone transfers, and cannot tell you who changed a DNS record last Tuesday, it might be time for a different approach.