Otukan checks where your app’s sensitive requests are going and flags any that would reach somewhere other than your servers. It checks that protected hostnames resolve and connect to endpoints you have declared, looks for resolver changes and local overrides on the device, and detects hooking of the app’s own lookup code. Moving backends and enterprise networks are declared before enforcement, and when a check fails the app holds the sensitive request instead of sending it to an unknown server. This control covers where a connection goes; protocol strength and key pinning are separate controls on Android and iOS.
This control sits inside network protection.
Trust boundary
Redirection happens before encryption has a chance to help. Separating the layers shows where connection integrity works.
| Layer | The question | Who answers it |
|---|---|---|
| Name resolution | Did this hostname resolve to one of our endpoints? | Connection integrity, on the device |
| Connection set-up | Is the socket open to the endpoint we expected? | Connection integrity, on the device |
| Transport validation | Is the channel strong and the certificate valid for this name? | Platform TLS, tightened by connection hardening |
| Server identity | Does the server hold the key we declared? | Certificate pinning, for selected domains |
| App identity | Is a genuine app on a genuine device calling? | App attestation, verified by your backend |
Hostile intermediaries
A rogue access point can answer lookups with its own addresses. A malicious app or profile can change the resolver the device uses. On a rooted or jailbroken device, a local entry can send one hostname anywhere. Each of these leaves a trace at a different layer, and Otukan checks each layer separately.
On Android and on iOS
On Android, Otukan looks at how the app’s own requests resolve, whether a private DNS setting or a VPN-based resolver is in the path, and, on rooted devices, whether local entries override your hostnames. On iOS, apps see less of the system configuration, so Otukan concentrates on where the app’s own connections land against your declared endpoints, on whether a VPN or proxy configuration is active, and on local overrides that a jailbreak makes possible. Each platform has its own checks and its own test cases.
App and backend identity
Reaching the right server is necessary, not sufficient. Your backend still decides whether to trust the caller, using Otukan runtime signals and, where you use it, attestation. For that side of the boundary, see mobile app attestation.
Lifecycle
Legitimate change looks like redirection unless you plan for it.
Endpoint and certificate changes
Backends move: a new region, a new content delivery network, a replacement load balancer. Each protected hostname has a declared set of destinations, updated before your infrastructure team makes the move. Certificate renewals on the same endpoints do not affect these checks; certificate trust is handled by the transport and pinning controls.
Network transitions
When a device switches from Wi-Fi to mobile data, cached answers from the old network can linger. Otukan re-checks protected hostnames after a network change instead of trusting a lookup made somewhere else.
Approved enterprise resolvers
Corporate networks often run their own resolvers and split DNS, so an internal name resolves differently at the office. Your team declares these as approved exceptions per hostname, and they are tested before enforcement.
Availability
A check that blocks the only route to your backend becomes an outage. Otukan settles failure behaviour first.
Failure handling
When a protected hostname resolves outside the declared set, the request is held and the event is recorded. Browsing and content that carry no sensitive data can continue.
Fallback
The app does not fall back to an undeclared destination for a sensitive request. It re-resolves on the next network change, retries against declared endpoints or asks the user to move to a trusted network.
Recovery
Each hostname can also be switched back to observe mode on its own, so a problem with one endpoint does not force enforcement off for the rest of the app.
Events arrive grouped by hostname and network type. Many failures on one hostname after an infrastructure change point to a missing declaration; scattered failures on public networks point to redirection. Before enforcement, Otukan works with your team to reproduce each redirection path in an authorised lab, repeat the same journeys on legitimate networks, and rerun install, update, sign-in and your most sensitive flow, recording versions, devices and the reviewer.
For interception on a connection that did reach the right name, see man-in-the-middle prevention.