HTTPDNS:Troubleshoot DNS resolution with session tracing

Use session tracing when:

• HTTPDNS returns an unexpected IP address that affects your business.

How DNS scheduling works

DNS servers return IP addresses based on the visitor's source IP. GSLB frequently updates scheduling rules — for example, CDN scheduling may change every few hours. If a client receives an incorrect IP, users may experience slow responses, timeouts, or service unavailability.

Troubleshooting requires the source IP, resolution time, domain name, and resolved IP list. However, source IP-based troubleshooting has several limitations:

• The client may not know its accurate source IP.

• The source IP is often shared (NAT) and insufficient for pinpointing the issue.

• Carriers may assign different source IPs depending on the destination.

• The source IP may change during the application lifecycle.

• The cause of source IP changes cannot be identified from the IP alone.

How session IDs work

A sessionId is generated when an application starts and remains constant throughout the application lifecycle. Every HTTPDNS request in that lifecycle carries the same sessionId, which the server indexes. This approach identifies resolution records by application lifecycle rather than by source IP, providing a more accurate troubleshooting method.

With the sessionId, you can obtain the client's exact source IP and trace all HTTPDNS requests in a single application lifecycle. By observing changes in the net parameter, you can identify when and why the source IP changed.

For example, a client using a Guangdong carrier's SIM card on a 4G network gets a Guangdong source IP. HTTPDNS returns an IP based on that location. When the client switches to a wired network or Wi-Fi in another province, the source IP changes and the previous resolution result becomes stale. This affects service quality regardless of whether traditional DNS or HTTPDNS is used.

Record session IDs

Upgrading an application takes time. Record resolution results and session IDs from the start so you can troubleshoot issues immediately when they occur.

• SDK access: A session ID is generated on app startup. Call getSessionId to retrieve it. Minimum SDK versions: Android 1.2.3, iOS 1.6.20. Update to the latest version to avoid known issues.

• HTTP API access: Configure the required parameters based on the HTTPDNS SDK source code.

• When your application reports scheduling quality issues, record the sessionId value.

You can also append the sessionId to your service requests. For example, add it to the URL when requesting a service using the HTTPDNS-resolved IP. This lets you correlate resolution results with actual service calls.

The SDK adds the following parameters to each HTTPDNS request:

• sid=<sessionId:[a-zA-Z0-9]{12}>: identifies the application lifecycle. Generated on SDK startup.

• net=<4g|3g|2g|wifi|unknown>: the network type reported by the OS at request time.

• bssid=<wifi_bssid>: the Wi-Fi access point identifier.

• Sample URL: http://47.74.222.190/902379/dhost=www.aliyun.com&sid=wInhNA3iM0PK&net=wifi&bssid=54e061553e79

Troubleshoot unexpected resolution results

If you suspect an HTTPDNS resolution error, submit a ticket with the following information:

• The sessionId, resolution time, domain name, actual result, and expected result.

• A description of the impact, such as being routed to the wrong region.

• Whether the service is still available.

If service quality is affected, obtain a fresh resolution result from HTTPDNS or your on-premises DNS server as soon as possible, then verify service quality again.

Based on your session ID, Alibaba Cloud provides:

• The source of the resolution result.

The result may come from an HTTPDNS server, an on-premises DNS server, or the persistent cache.

• The network environment and source IP for this resolution.

• Whether the source IP changed during the application lifecycle due to client movement.