All Products
Search
Document Center

HTTPDNS:Verify using a hijack simulation

Last Updated:Dec 03, 2025

After you integrate the Android SDK, you can verify that HTTPDNS is working correctly by simulating a Local DNS failure. This topic describes the methods and steps for this test.

How it works

HTTPDNS sends resolution requests directly to Alibaba Cloud DNS servers over HTTP or HTTPS. This process bypasses the system's Local DNS and prevents DNS hijacking or resolution failures that are caused by network issues.
A mobile device typically uses the Local DNS provided by its current network. For a Wi-Fi connection, the device uses the DNS that is configured on the router or provided by the carrier. For a mobile data connection, the device uses the carrier's DNS. In a Wi-Fi environment, you can change the state of the Local DNS by changing the Wi-Fi DNS settings. Setting the Wi-Fi DNS to an invalid address creates an environment where Local DNS resolution fails. When you make a network request in this simulated hijack environment:

  • If the request is successful, it indicates that the request bypassed the Local DNS and that the HTTPDNS integration is successful.

  • If the request fails, it indicates that the request still depends on the Local DNS and that the HTTPDNS integration has failed.

Prerequisites

  • Test device: An Android phone that lets you manually change Wi-Fi DNS settings.

  • Network environment: A Wi-Fi connection that lets you manually change its DNS address.

  • App status: The app is integrated with the EMAS HTTPDNS SDK.

  • Test domain name: A service domain name that is configured and used in the Alibaba Cloud HTTPDNS console.

Procedure

Step 1: Verify in a normal network environment

  1. Connect the test device to any available Wi-Fi network. Keep the default DNS settings.

  2. With HTTPDNS disabled, open your app and trigger a network request that uses a domain name, such as loading the home page or calling an API.

  3. Confirm that the request is successful.

Note

This step establishes a baseline. It ensures that the app and its services work correctly in a normal network environment.

Step 2: Simulate a Local DNS resolution failure

  1. On your test device, go to the Wi-Fi settings. Press and hold the name of the connected Wi-Fi network, and then select "Modify network" or "Advanced options".

  2. Change the IP settings to "Static".

  3. In the DNS 1 and DNS 2 fields, enter invalid IP addresses, such as 1.2.3.4 or 100.100.100.100. This ensures that the Local DNS cannot resolve domain names.

    Note

    Note: Do not use valid public DNS addresses, such as 114.114.114.114 or 8.8.8.8.

  4. Save the configuration and reconnect to the Wi-Fi network.

Step 3: Verify in the simulated hijack environment

  1. Confirm that the device is connected to the Wi-Fi network that you modified in Step 2. The DNS for this network must be set to an invalid address.

  2. Turn off the mobile data connection. This prevents the system from automatically switching to the mobile network if the Wi-Fi connection fails.

  3. Enable HTTPDNS, open your app, and trigger the same service request as in Step 1, such as loading the home page or calling an API.

  4. Observe the request result:

    Request result

    Conclusion

    Network request succeeds

    The request bypassed the Local DNS. Domain name resolution was completed by HTTPDNS. This indicates that HTTPDNS is integrated successfully.

    Network request fails

    • If the first request fails, it might be due to a cache miss that caused a fallback to Local DNS. Wait a moment and retry.

    • If multiple requests still fail, the app still depends on the Local DNS. The resolution fails in the simulated hijack environment. This indicates that HTTPDNS integration failed.

    Note

    If you use a synchronous non-blocking API for domain name resolution, enable pre-resolution using the setPreResolveHosts method and allow the use of expired IP addresses using the setEnableExpiredIp method. This ensures that resolution results are available in the local cache. This practice prevents fallbacks to Local DNS that are caused by a cache miss, which can affect the accuracy of the verification.