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
Connect the test device to any available Wi-Fi network. Keep the default DNS settings.
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.
Confirm that the request is successful.
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
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".
Change the IP settings to "Static".
In the DNS 1 and DNS 2 fields, enter invalid IP addresses, such as
1.2.3.4or100.100.100.100. This ensures that the Local DNS cannot resolve domain names.NoteNote: Do not use valid public DNS addresses, such as 114.114.114.114 or 8.8.8.8.
Save the configuration and reconnect to the Wi-Fi network.
Step 3: Verify in the simulated hijack environment
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.
Turn off the mobile data connection. This prevents the system from automatically switching to the mobile network if the Wi-Fi connection fails.
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.
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.
NoteIf 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.