DNS Shield

DNS Shield is CNX's authoritative DNS service: anycast-distributed across independent nodes in Cambodia, with DNSSEC signed on every zone and signing keys held in hardware security modules inside Cambodia. Public-internet traffic is handled by dedicated bulkhead servers on dedicated transit links, isolated from the domestic fleet.

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.

Public internet — isolated bulkhead servers use dedicated transit links and are separated from the domestic fleet. Requests and attacks arriving through international transit terminate on this external-facing capacity rather than creating a path into the domestic service fabric.

Overseas anycast nodes are planned as a later extension of this architecture; they are not part of the current service footprint.

A single authoritative server has a fixed ceiling, and a DDoS attack is just a search for the traffic level that exceeds it. Anycast distributes capacity across independent nodes rather than concentrating it in one place, and additional nodes or capacity can be introduced without changing the service address. Domestic traffic is served on the national fabric; traffic arriving through international transit is contained by the separate bulkhead fleet. This isolation prevents an attack on the public-internet path from becoming an attack path into the domestic DNS fleet.

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.

Policy-enabled hostnames and failover policies are included — see Pricing for capacity and plan details.

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. Every production zone change requires dual authorisation: one authorised person proposes the change and a different authorised person must approve it before deployment. Nobody can approve their own change. This two-person control implements the principle defined by NIST SP 800-53 CM-5(4), while the SSO-integrated Git workflow produces an immutable audit record for NBC TCRMG change management requirements.

Premium customers can also ingest customer-isolated live DNS operations, platform, sampled query-detail, and unsampled query-summary feeds into their own SIEM. These feeds support operational correlation and supplement the retained daily signed audit reports.

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 the domestic and bulkhead infrastructure.
• Compliance documentation — audit reports, key management records, and change logs structured for NBC TCRMG examination requirements.
• Live DNS telemetry (Premium) — customer-isolated operations, platform, sampled query-detail, and unsampled query-summary feeds for SIEM ingestion and operational correlation.

During an attack — protect the domestic path

Domestic nodes carry no public internet routes, so an attack arriving over international transit has no direct path into the domestic fleet. It is handled by dedicated bulkhead servers and transit links instead. Domestic attacks are absorbed on the national fabric; because CNX operates the national IXP fabric itself, attacking sources can also be filtered at the exchange and coordinated with member ISPs using Remote Triggered Black Hole (RTBH) routing. The objective is to preserve the in-country resolution path even while the public-internet path is under attack.

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%
Public internet
Query path	Queries arriving through international transit are served by dedicated bulkhead servers on dedicated transit links, isolated from the domestic fleet. Overseas anycast nodes are planned but are not currently deployed.
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.