Network context, DNS, and zero-rating

The challenge

On many African mobile networks, DNS resolution is a frequent silent failure point. YinkoShield observes DNS-related timeouts and partial failures in production across 2024–2025 deployments; specific percentages, sample, window, and geography are documented in the operator-side field report and will be published once the next data window closes (see What’s next below). The downstream effects look like security incidents — false fraud alerts, abandoned transactions, mid-flow session resets — but the cause is upstream of the security stack.

A user on a constrained network whose banking app cannot resolve hostnames cannot transact. The downstream cost falls on operators serving emerging-market estates where carrier-DNS reliability is the limiting factor for transaction completion.

Why we built this inside the runtime

A secure transaction that never completes is as ineffective as an unprotected one. Our threat-detection logic should not penalise users for network conditions outside their control. The runtime that signs execution evidence is also where we can intervene at the network-resolution layer — without putting additional external services in the trust path beyond the resolvers the operator has explicitly configured.

DNS Racer ships as part of the YinkoShield SDK update and runs entirely inside the host mobile application; the resolvers it queries are the standard public DoH/DoT endpoints (RFC 8484 [1], RFC 7858 [2]) and any operator-configured private resolvers.

How it works

DNS Racer queries multiple resolvers in parallel:

• Classic DNS (UDP/TCP port 53) — fastest where the carrier network is healthy, with no transport-layer authentication of the resolver itself.
• DNS-over-HTTPS (DoH) [1] — DNS resolution tunnelled over HTTPS to a known endpoint, with the TLS endpoint pinned by the SDK.
• DNS-over-TLS (DoT) [2] — DNS over a dedicated TLS port (853), pinned the same way.
• Operator-configured resolvers — additional resolvers the operator has approved via the SDK’s signed configuration channel. (These extend the trust surface to whoever runs the resolver: a hostile or compromised operator-configured resolver becomes a poisoning vector, so the configuration is signed and the resolver endpoints are pinned.)

It picks the first valid response that passes the appropriate integrity checks for the channel it arrived on:

• Transport authentication of the resolver — TLS pinning on the DoH and DoT channels — protects against an attacker impersonating the resolver itself.
• Record authenticity — DNSSEC validation [3] where the zone is signed and the resolver supports it — protects against a (cryptographically detectable) modification of the records end-to-end.

These two controls operate at different layers: TLS pinning protects the channel between the device and the resolver; DNSSEC protects the integrity of the records the resolver returns. They are complementary, not interchangeable, and DNSSEC’s effectiveness is bounded by zone-signing coverage on the operator’s destination domains.

Adaptive to network and location

In urban networks with good connectivity, DNS Racer prioritises encrypted DNS for privacy. In rural or slow-network conditions, it falls back to faster local resolvers and caches more aggressively. The decision is made on the device, in real time.

DNS Racer is embedded in the host application. The SDK’s in-process resolver substitution path is the same on both platforms in API surface, but the platform-level posture differs:

• Android. The host app’s HTTP stack uses the SDK’s resolver directly; the SDK selects from the racer’s candidates per request without requiring a system-wide DNS setting.
• iOS. In-process resolver substitution is the same, but device-wide DNS substitution requires the Network Extension framework — NEDNSProxyProvider or NEDNSSettingsManager [4] — which needs a separate provider target and the Network Extension entitlement. Operators that want the SDK’s resolver policy applied beyond the host app’s own traffic must budget for the additional Network Extension integration.

DNS Racer runs on the SDK’s supported low-end Android baseline (specific OS / RAM floors are documented in the SDK release notes).

Zero-rating, in practice

A dedicated DoH endpoint preserves zero-rating only where the carrier has agreed to allowlist that endpoint’s IP and SNI. Carriers implement zero-rating by inspecting destination IP / SNI / domain hostname; encrypting the DNS path means the carrier cannot classify the traffic against the zero-rated bundle unless the DoH endpoint is on the allowlist. In practice this is a per-carrier coordination cost — a real cost — and DNS Racer’s operator-configured-resolver path is where operators wire the DoH endpoint they have negotiated with their carrier partner.

The operational outcome

The design target with DNS Racer enabled is faster DNS resolution, fewer session timeouts, and more consistent access to banking features for users on unstable networks. The intended downstream effects for operators are higher transaction-success rates, reduced support overhead, and stronger user trust; for fraud teams, fewer false-positive incidents driven by network flapping rather than adversarial behaviour. Quantified deltas (transaction-success deltas, session-abandonment reductions, support-ticket impact) will publish with the next data window — see What’s next.

Why this fits the witness layer

DNS Racer is the same shape as the rest of the substrate. It runs in the device, declares what it observed and what it chose, and emits its decision into the evidence record. The operator can verify that the network path was the one expected — and reason about it forensically when something looks unusual. A reliable network is part of execution coherence; a signed record of how that reliability was achieved is part of the witness register that Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — emits.

What’s next

The next published data window will include field performance metrics from production deployments — transaction-success deltas, session-abandonment reductions, support-ticket impact — with sample, window, and geography labelled, across the markets where DNS Racer is in front of real users.

External references

[1] IETF. RFC 8484 — DNS Queries over HTTPS (DoH). datatracker.ietf.org/doc/html/rfc8484. Cited 2025-06-15.

[2] IETF. RFC 7858 — Specification for DNS over Transport Layer Security (DoT). datatracker.ietf.org/doc/html/rfc7858. Cited 2025-06-15.

[3] IETF. RFC 4033 — DNS Security Introduction and Requirements (DNSSEC). datatracker.ietf.org/doc/html/rfc4033. Cited 2025-06-15.

[4] Apple Developer. Network Extension — NEDNSProxyProvider and NEDNSSettingsManager. developer.apple.com/documentation/networkextension. Cited 2025-06-15.

[5] Android Developers. Private DNS (DNS-over-TLS) on Android 9+. developer.android.com/training/articles/perf-tips#PrivateDNS. Cited 2025-06-15.