DNS Shield

DNS Shield is CNX's authoritative DNS service: anycast-distributed across independent nodes in Cambodia, Southeast Asia, Europe, and the Americas, with DNSSEC signed on every zone and signing keys held in hardware security modules inside Cambodia.

How it works

DNS Shield uses anycast: the same IP address is announced from multiple locations simultaneously. Every query is answered by the nearest node. There is no single point of failure.

Inside Cambodia — multiple independent nodes interconnected via the national IXP fabric at 100GE, with direct private peering to Cambodia's largest carriers on isolated segments. These nodes carry no public internet routes — they are structurally unreachable from outside the country.

Outside Cambodia — international edge nodes in Singapore, Japan, Germany, and the USA. These nodes act as regional traffic sinks — volumetric attack traffic is drawn to and consumed at the nearest node, never reaching Cambodia.

A single authoritative server has a fixed ceiling, and a DDoS attack is just a search for the traffic level that exceeds it. Anycast removes the ceiling: capacity is distributed across independent nodes rather than concentrated in one place, and additional nodes or capacity can be brought in without a cutover or a single point that has to hold. Domestic attacks are absorbed on the national fabric; attacks originating overseas are drawn to and absorbed at the nearest international edge node, geographically closer to the attack source than to Cambodia, so they never cross into the domestic fabric at all. Either way, DNS Shield scales with the attacker instead of racing to stay ahead of a known limit.

Policy views — from routing data, not guesses

DNS Shield can answer differently depending on where a query is actually coming from, using CNX's own routing data from the exchange fabric — not a GeoIP database inferring location from static IP registration records. Whether a querying network sits on the exchange is a fact CNX already knows, not an estimate.

Health-checked failover — based on confirmed service state

Shield can monitor primary, secondary, and fallback origins from multiple CNX-connected locations inside Cambodia. Each origin exposes a customer-defined health endpoint with a clear readiness response. CNX combines the results using a quorum policy, so a single routing issue or failed probe does not trigger a service change.

When the primary origin is confirmed unavailable and the next destination is confirmed healthy, Shield automatically updates the managed DNS path. Policies can support primary-to-secondary failover, global service or other approved fallback, and automatic return to the preferred origin after a defined period of stable health. Failover logic, recovery timers, TTLs, and destination order are agreed during onboarding and pragmatically implemented.

Included free with every plan: up to 5 managed failover policies with up to 3 origins each, across up to 10 policy-enabled hostnames. Additional capacity is available on request — see Pricing.

Two input paths

Zone Transfer — your team keeps your existing DNS workflow. CNX connects to your authoritative server, signs and distributes your zone on the anycast network. Your operations team makes no changes to how DNS records are managed today.

CNX Managed Origin — no DNS infrastructure required. Zone changes go through an approval workflow that produces an immutable audit record, satisfying NBC TCRMG change management requirements. Integrates with your existing Single Sign-On.

What CNX operates on your behalf

• HSM infrastructure — DNSSEC signing keys generated, stored, and rotated inside hardware security modules in Cambodia. Non-exportable. Key rollover is automated — no maintenance windows, no stale keys.
• 24/7 monitoring — continuous monitoring of both service availability and DNSSEC validity across every node. Alerts before problems become outages.
• Anycast network operations — node health, BGP route management, and traffic distribution across domestic and international infrastructure.
• Compliance documentation — audit reports, key management records, and change logs structured for NBC TCRMG examination requirements.

During an attack — Cambodian users see nothing

During a volumetric attack, your Cambodian users are unaffected. Domestic nodes carry no public internet routes — they are structurally unreachable from outside the country regardless of attack volume. The domestic anycast network is provisioned to absorb several hundred Gbps on its own, sinking the largest domestic attack directly at the node. Because CNX operates the national IXP fabric itself, attacking sources can also be filtered at the exchange, and coordinated with member ISPs for Remote Triggered Black Hole (RTBH) routing — dropping attack traffic at the network edge before it reaches a DNS node at all. International edge nodes absorb traffic from their respective regions. From inside Cambodia, your domain resolves exactly as it always does. The attack is invisible to your users.

Zone completeness — every record, on every node, always

Some DNS protection services learn your zone by scanning publicly-reachable records — querying for A, MX, and NS entries to build a working copy. Records with unpredictable names are invisible to a scanner that does not know what to ask for: DKIM selectors, SPF policies, DMARC configuration, verification tokens, API endpoint definitions. If that service ever serves from its learned copy rather than your origin — because your origin is down, or because traffic is being scrubbed — those records are gone. The domain appears to work. The authentication layer does not. Nobody notices until email stops being delivered or a domain verification fails.

DNS Shield receives your complete zone via authenticated transfer from your authoritative server, or directly from the CNX-managed repository. Every record is present on every node — every subdomain, every TXT entry, every selector. The zone is cryptographically signed with DNSSEC; any omission or modification in transit is detectable and rejected. There is no learned copy. There is only the complete zone.

Onboarding — from evaluation to live, with no production risk

Before your DNS is live on CNX, we run in parallel. Your existing DNS keeps operating exactly as it does today — no changes to registrar records, no impact on users.

1. CNX imports your current zone records.
2. CNX serves your zones from the anycast network — your registrar still points to your current provider. Nothing changes for users.
3. Your team queries the CNX nameservers directly to verify every record, check latency, and confirm DNSSEC signatures — at your own pace, with no time pressure.
4. When your team is satisfied, registrar NS records are updated. This is the only change with any user-facing effect, and it propagates gradually as DNS caches expire.
5. Your previous provider remains available as a fallback for at least seven days after cutover.

Rollback at any time: pointing your registrar records back to your previous provider restores the previous state. The exit is a single DNS change.

Service levels

In-country
Query path	Queries from Cambodian networks resolve entirely on the CNX exchange fabric. Each major carrier connects to a dedicated isolated segment — ISP traffic is served from its own capacity, with no contention between networks. A query from a user on any Cambodian ISP never leaves the national exchange fabric to reach an answer.
Latency	Under 10 ms from resolver to CNX node, across every Cambodian carrier
Uptime SLA	99.99%
International
Query path	International nodes are colocated at major internet exchanges alongside the world's largest public resolvers — Google (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9). Users outside Cambodia on public resolvers receive answers with minimal additional latency; CNX sits where those resolvers peer.
All nodes
Query limits	None. Attack traffic costs nothing extra.
Zone propagation	Typically seconds · SLA under 5 minutes
DNSSEC	Every zone, by default. Keys in HSMs, automated rollover per RFC 6781
Monitoring	24/7 availability and DNSSEC validity

Standards

DNS Shield implements DNSSEC per RFC 4033–4035, using ECDSAP256SHA256 — NIST P-256 with SHA-256, the RECOMMENDED algorithm under RFC 8624 — as the only signing algorithm. Deprecated algorithms are not accepted. Key rollover follows RFC 6781. Zone transfer authentication uses TSIG per RFC 8945. Signing keys are generated and stored in dedicated hardware security modules; they are non-exportable by hardware design.

Full standards and regulatory compliance mapping — including NBC TCRMG chapter-by-chapter, NIST SP 800-81, and RGC Cloud First Policy alignment — is on the Compliance page.

Your zone data stays yours

Zone files are maintained in standard BIND format — the open format used by every DNS operator on the internet. At any point you can export your complete zone and take it to any other provider. There is no proprietary format, no data migration, no lock-in. The rollback process described in onboarding is identical to a full exit: update your registrar records, done.