DNS Resolver

The CNX DNS Resolver is a private DNS resolver dedicated to a single mobile or web application. It is provisioned per customer, tuned to that application's own domains and dependencies, and answers over standard encrypted DNS transports: DoH (RFC 8484), DoT (RFC 7858), and DoQ (RFC 9250). Integration is a standard resolver client pointed at the assigned endpoint, and every answer comes from inside Cambodia.

What problem it solves

When a carrier or ISP loses its connection to the outside world — a cut submarine cable, a congested international gateway, a peering dispute — any application whose DNS resolution depends on an overseas resolver goes down with it, even though the app's own servers and authoritative DNS never left Cambodia. The domain simply stops resolving. This is a resilience problem first: DNS is one of the quietest ways a domestic service ends up depending on infrastructure outside the country, because nobody chose it deliberately. Field testing across Cambodian public WiFi networks found that most access points hand out a resolver that answers from outside Cambodia — Google's 8.8.8.8 is common, resolving from Vietnam, Singapore, or Hong Kong — and several networks silently forward all DNS traffic overseas regardless of which resolver a device actually requests.

That silent dependency is also a sovereignty problem. A guarantee that traffic stays inside Cambodia is only as strong as its weakest link, and DNS resolution is very often the one link nobody audited. The CNX DNS Resolver removes the ambiguity: every query the app makes is answered inside Cambodia, by infrastructure under Cambodian jurisdiction — not a best effort, a guarantee.

Keeping resolution in-country is also dramatically faster — a cold DNS lookup drops from as much as 300 ms to single-digit milliseconds:

Scenario	Measured latency
Resolver overseas, authoritative in-country	200–340 ms
Both resolver and authoritative overseas	~70 ms
Both resolver and authoritative in-country	5–15 ms

How to integrate it

The app points a standard resolver client at its assigned CNX endpoint, using whichever of the three transports fits its stack:

• DoH — DNS over HTTPS (RFC 8484) — a request to a /dns-query endpoint over ordinary HTTPS. Any HTTP client already in the app can speak it: URLSession on iOS, OkHttp or Cronet on Android.
• DoT — DNS over TLS (RFC 7858) — a TLS connection on port 853. Supported by every platform's TLS stack directly.
• DoQ — DNS over QUIC (RFC 9250) — the fastest of the three for an app making repeated queries against the same resolver: a 1-RTT handshake on a new connection, 0-RTT on a resumed session. Apple's Network.framework (iOS 15+) and Android's Cronet QUIC engine both expose a QUIC connection with a configurable ALPN, enough to speak DoQ directly against OS-provided primitives. Teams that prefer a ready-made client can use an open-source DoQ implementation such as AdGuard's DnsLibs, which ships Kotlin bindings for Android and Swift bindings for iOS.

Encrypting DNS protects the application from network-level DNS hijacking and manipulation of DNS records — an on-path attacker cannot read, spoof, or redirect a query it cannot see inside. The CNX resolver service only offers secure DNS access: plain DNS over UDP or TCP (RFC 1035) is not offered.

What the service delivers

• Dedicated — a private resolver instance and cache, provisioned for your application.
• Pre-warmed cache — every domain the application depends on is loaded into cache ahead of time, so the first query an app makes is as fast as the thousandth. There is no cold-start lookup.
• Tuned caching rules per dependency — third-party domains the app relies on but doesn't control (analytics, payment gateways, CDNs) get cache rules set deliberately, rather than inheriting whatever TTL that provider happens to publish.
• Answers from in-country cache, even during an outage — because the domains an app needs are already resolved and held locally, DNS resolution keeps working even if Cambodia's international links are degraded or unreachable.
• Glue to your authoritative DNS — the resolver holds a glue record straight to your in-country authoritative nameserver, so it already knows where to find your domain regardless of TLD — .com, .net, .kh, whatever it's registered under. For applications also running on DNS Shield, lookups for the app's own domain never leave CNX infrastructure at all.

Measured performance (in-country resolver + authoritative)

Network	Total DNS time	Breakdown
WiFi	3–15 ms	DNS ~1 ms · Radio 3–15 ms
Mobile (4G/5G)	35–55 ms	DNS ~1 ms · Radio 30–40 ms

Capacity and SLA

The instance is sized to the application's concurrent query volume at launch, and scales as usage grows — tell us what you need today and what you expect at peak, and capacity is provisioned accordingly.

Allocation	A dedicated instance and cache, sized to your application's query volume
Platform ceiling	500,000+ QPS recursive capacity available on the platform
Redundancy	Across Phnom Penh PoPs — no single point of failure

Standards

The resolver answers DNS over HTTPS per RFC 8484, DNS over TLS per RFC 7858, and DNS over QUIC per RFC 9250 — no other transport is offered. All three are served from the same dedicated instance; there is no separate product tier per transport.