Compliance

This page covers DNS Shield — both the Zone Transfer and Managed Origin tiers. CNX DNS is built to a defined set of protocol, cryptographic, and regulatory standards. The table below gives a full-picture summary. The NBC TCRMG chapter mapping follows.

Standards overview

Standard or framework	Applicability to CNX DNS
NBC TCRMG (January 2026)	National Bank of Cambodia Technology and Cyber Risk Management Guidelines (January 2026, supersedes 2019 version). Full chapter mapping below — Chapters 3, 4, 5, 7, and 8.
RGC Cloud First Policy	Data sovereignty and in-country infrastructure requirements. Core DNS nodes operate in domestic data centres; encryption key governance aligns with RGC control requirements.
TRC (Telecom Regulator of Cambodia)	DNS classified as Critical Information Infrastructure. DNSSEC readiness supports TRC objectives for national domain security.
DGC (Digital Government Committee)	Open standards and ICT interoperability. BIND-format zones and RFC-compliant DNSSEC support DGC interoperability requirements.
RFC 4033 · 4034 · 4035	DNSSEC core protocol — DNS Security Introduction, Resource Records, and Protocol Modifications. All zones signed.
RFC 8624	Algorithm Implementation Requirements for DNSSEC. CNX uses ECDSAP256SHA256 (NIST P-256 / SHA-256), classified RECOMMENDED. Deprecated algorithms are not accepted.
RFC 6781	DNSSEC Operational Practices — key rollover procedures. Rollover is fully automated; no manual intervention required.
RFC 8945	TSIG Secret Key Transaction Authentication — used to authenticate zone transfer sessions between customer servers and CNX.
NIST FIPS 186-4	Digital Signature Standard. ECDSAP256SHA256 uses NIST P-256 (secp256r1) and SHA-256 as specified in FIPS 186-4 — the algorithm specification, independently of implementation certification.
NIST SP 800-57	Key Management Recommendations. Key lifecycle — generation in hardware, access control, rotation schedule, and destruction — is aligned with SP 800-57 guidance.
NIST SP 800-81 Rev 2	Secure DNS Deployment Guide. CNX DNS architecture and operational practices are aligned with NIST guidance for secure authoritative DNS deployment.

---

NBC TCRMG — detailed mapping

DNS is the service that directs every customer to a bank's digital presence. A compromised, unavailable, or spoofed DNS response is the earliest point at which an attack on internet banking, mobile banking, or payment services can succeed. The TCRMG (January 2026) requirements for cybersecurity, digital service protection, and operational continuity apply directly to DNS as the foundational layer beneath all of them. The sections below map CNX DNS capabilities to specific TCRMG requirements.

IT Operations Management (Chapter 3)

Requirement	How CNX DNS addresses it
Technology Risk Management Framework (3.1)	CNX DNS provides documentation of inherent risks — DoS, domain hijacking, single points of failure — and the technical controls that mitigate them, supporting the BFI's TRMF with a clearly framed third-party risk entry.
Configuration Management (3.3)	The GitOps workflow maintains an immutable version-controlled record of every DNS configuration change. All changes are identified, recorded, and require authorisation before deployment — implementing 3.3.1 and 3.3.2 directly.
Change Management (3.6)	Every zone change is submitted, automatically validated, approved by a designated authority, and propagated with a full audit record. No change reaches production without documented authorisation — meeting 3.6.1, 3.6.4, and 3.6.5.
Incident Management — DoS Prevention (3.8.8)	Anycast architecture absorbs volumetric attacks at international edge nodes before traffic enters Cambodia. The BFI's domain remains available during attack conditions that would take down a single-origin nameserver.
Capacity and Performance Management (3.10)	Daily performance reports and real-time operational data are provided. Service performance is continuously monitored against defined thresholds — meeting 3.10.1.
Backup and Recovery (3.12)	All DNS records are held in the BFI's own systems and replicated on the CNX platform. A secure in-country backup facility ensures data restoration is possible (3.12.3) and that backup media is protected (3.12.4).
Data Centre Resiliency (3.13)	Authoritative DNS nodes operate across multiple independent domestic data centres via anycast delivery — eliminating single points of failure and providing the redundancy and fault tolerance required by 3.13.2 and 3.13.3.
Supplier Relationships (3.17)	CNX provides the documentation and compliance evidence necessary for the BFI to exercise mandated oversight of outsourced technology services, with contractual provisions supporting information security controls at 3.17.1 and 3.17.3.

Cybersecurity Management (Chapter 4)

Requirement	How CNX DNS addresses it
Cyber Risk Management Framework (4.1)	Audit and compliance reports support the BFI's cyber risk assessments including third-party risk. Operating high-security DNS reduces exposure to domain hijacking, supporting continuous CRMF updates.
Access Control (4.3)	The platform integrates with the BFI's Single Sign-On (SSO) via SAML 2.0. Role-based access control enforces least privilege and separation of duties between change submitters and approvers — meeting 4.3.3.
Cryptography (4.5)	DNSSEC provides cryptographic integrity and authenticity for all published DNS records. Cryptographic protection applies to data in transit and at the signing layer.
Key Management and HSM Protection (4.5.6)	Zone Signing Keys (ZSK) and Key Signing Keys (KSK) are generated and stored exclusively in Hardware Security Modules across multiple independent sites. Keys are non-exportable. Access is physically controlled and audited. Meets the mandatory requirement to protect keys against modification, loss, and unauthorised disclosure.
Key Lifecycle Auditing (4.5.8)	All key management activities — generation, rollover, usage — are logged. Audit records of key lifecycle events are mandatory under 4.5.8 and are delivered in daily signed reports.
Network Security (4.7)	Anycast delivery provides a network architecture with no single point of failure, protecting against network faults and volumetric attacks — meeting 4.7.6.
Audit Trails and Non-Repudiation (4.10)	Immutable Git audit logs tie every configuration change to a unique user identity and an approval record. All operational, signing, and key lifecycle events are aggregated into daily timestamped reports, protecting log integrity from unauthorised modification — meeting 4.10.6.

Business Continuity Management (Chapter 8)

Requirement	How CNX DNS addresses it
Business Impact Analysis and Recovery Objectives (8.0.3)	CNX defines a Maximum Tolerable Downtime of 48 hours for the change management system (Hidden Master). During that window, DNS resolution continues fully from anycast nodes. The defined MTD directly informs the BFI's BIA calculation for outsourced DNS.
Recovery Time Objective — DNS availability (8.0.4, 8.0.5)	RTO for the DNS resolution service is under 60 seconds. Redundant anycast nodes across domestic and international sites maintain service continuity with near-zero customer impact during any single-site failure.
Disaster Recovery Plan (8.0.7)	RTO for the change management and signing authority is 48 hours. Recovery is based on configuration-as-code (Ansible) and encrypted offsite repository backups held domestically. The BFI's critical DNS systems can be restored within the defined RTO.
Review and Update of Plans (8.0.14)	CNX maintains and periodically tests an up-to-date DRP, supporting the BFI's obligation to review its DRP at least annually or following significant IT environment changes.

Digital Service Protection (Chapter 5)

Requirement	How CNX DNS addresses it
Risk and Security Assessments (5.0.1, 5.0.2)	CNX provides the security documentation and compliance attestations required for the BFI to perform risk and security assessments on the outsourced DNS service before launch and on a periodic basis.
DoS Attack Protection — Internet and Mobile Banking (5.1.3, 5.2)	Anycast DDoS absorption provides the first line of defence against attacks targeting the BFI's digital presence at the DNS layer — ensuring DNS remains available to direct customers to protected applications.
Secure Communication and Certificate Integrity (5.0.5)	DNSSEC ensures that DNS responses cannot be spoofed to redirect users to malicious endpoints. The integrity of the DNS layer is foundational to the TLS handshake that establishes secure application sessions — protecting against man-in-the-middle attacks at their earliest point.

Technology Service Outsourcing (Chapter 7)

Requirement	How CNX DNS addresses it
Due Diligence and Monitoring (7.0.5, 7.0.15)	Daily signed audit reports, real-time access controls, and full operational visibility support the BFI's continuous monitoring obligations and third-party risk management under 7.0.5 and 7.0.15.
Data Segregation (7.0.11)	BFI DNS data is logically segregated from other clients on the platform. Secure data destruction upon contract termination is contractually committed as part of the CNX exit strategy.
Data Location Reporting (7.0.13)	Core DNS nodes and data processing operate in domestic data centres. Data location is documented and available for regulatory reporting — supporting the BFI's obligation to disclose when Cambodian operational data is processed outside the country (it is not).
Audit and Inspection Rights (7.0.17)	Service contracts include mandatory provisions granting the BFI and NBC the right to conduct outsourcing audits and obtain relevant control reports and inspection access.
Service Level Agreements (7.0.19)	CNX operates under defined SLAs with explicit performance expectations, service continuity requirements, and remediation provisions — meeting the mandatory SLA requirements for outsourced technology services.

Royal Government Cloud First Policy and TRC/DGC Alignment

The RGC Cloud First Policy emphasises data sovereignty, regulatory oversight, and in-country jurisdiction. CNX DNS is not a cloud service, but it directly addresses the sovereignty requirements the policy applies to ICT service providers: core infrastructure in domestic data centres, DNSSEC with hardware-backed key management, and operation under MPTC licensing with full audit capabilities.

The Telecom Regulator of Cambodia (TRC) classifies DNS as Critical Information Infrastructure. DNSSEC readiness demonstrates proactive engagement with TRC requirements for securing fundamental internet components. The Digital Government Committee (DGC) emphasis on open standards and interoperability is met through RFC-compliant DNSSEC and BIND-format zone management.