Background: Because of domain name hijacking (specifically, users in a certain area cannot ping the domain name or the access speed is very slow because the IP address of DNS resolution is across the network segment), the organization needs to locate it frequently for operation and maintenance, so the httpDNS solution is proposed.
Ideas are beautiful, reality is cruel. It's okay not to introduce this mechanism, but there are more problems after the introduction.
Pit 1: Because DNSPod charges, in order to save costs, we adopt the strategy of using local DNS first. If the server has a non-200 error code, we will switch to HttpDNS. As a result, there was a problem with one interface of the server, resulting in a large amount of traffic going through HttpDNS.
Solution: Only use HttpDNS for non-502 and non-200 return codes
Pit 2: The test is OK in the test environment. When many users access the official environment, nginx cannot perform load balancing and returns a 404 page.
Reason: In the current network environment, multiple egress IPs are loaded with the same nginx, and reverse proxy to more than a dozen services. When data passes through some gateways or proxies, the host information in the header is replaced with the ip in the url, resulting in nginx without domain name information and inability to distinguish services.
Solution 1: When adding Host in the message header, addX-Online-Host（具体没验证）
Solution 2:代理环境不要走HttpDNS，具体原因可以通过接下来的不太完善测试方案看出问题来
Pit 3: https certificate verification problem
Solution: Refer to the following link: HTTPS (including SNI) business scenario "IP direct connection" solution description
Overall: this technology is not yet mature (especially Tencent's DNSPod documentation is rough and rudimentary), and there are still many unknown network problems.
Here are some relatively complete help documents on Ali. It is recommended to read them carefully before considering whether to use them and how to use them.
HTTPDNS iOS, android (Android) platform: What problems should be paid attention to in the process of HTTPDNS access?
https://help.aliyun.com/knowledge_detail/41956.html?spm=5176.11065259.1996646101.searchclickresult.779a5af6PUztAf
HTTPDNS Android SDK Development Guide
https://help.aliyun.com/document_detail/30140.html?spm=a2c4g.11174283.6.576.2UQ2EO
Description of the "IP Direct Connection" Solution for HTTPS (including SNI) Service Scenarios
https://help.aliyun.com/document_detail/30143.html
Next, let's talk about my less-than-perfect test plan for Android:
Prepare tools:
1. One mobile device that supports setting manual proxy
2. Install the Fiddler tool on the PC
3. Apps that have integrated HttpDNS
Steps:
- Modify the Fiddler script to display relevant packet capture information
In the Main function add:
FiddlerObject.UI.lvSessions.AddBoundColumn("TrueServerIP",120,"X-HostIP");
FiddlerObject.UI.lvSessions.AddBoundColumn("HeaderHost",120,"X-Original-Host");
Among them, TrueServerIP identifies the IP used by the final access server, and HeaderHost identifies the domain name service corresponding to the URL IP address specified in the App terminal information.
After editing, click Save
Drag the split bar to see the new column, you can drag it to the first few columns
Modify OnBeforeRequest, fix the problem that Fiddler cleans up the Host in the header file, and add it at the end of the function
if (oSession.BitFlags & SessionFlags.ProtocolViolationInRequest)
{
var sOverride = oSession["X-Original-Host"];
if (!String.IsNullOrEmpty(sOverride))
{
oSession.oRequest["Host"] = sOverride;
oSession["X-overrideHost"] = sOverride;
oSession["ui-backcolor"] = "yellow";
// Be sure to bypass the gateway, otherwise overrideHost doesn't work
oSession.bypassGateway = true;
// FiddlerApplication.Log.LogFormat("host {0}, {1}", oSession["X-Original-Host"], oSession["X-overrideHost"]);
}
}
Save changes
2. Modify the Fiddler Host file to achieve domain name hijacking
Configure a non-existing IP
3. Set the mobile device network proxy server IP to the test PC's IP, and the port to 8888 (default)
4. Enter the App verification related functions that integrate HttpDNS , and use the no-cache interface for testing
5. View the Fiddler packet capture information to verify the effect of httpDNS
As shown in the figure, it shows that the httpDNS is successful.
6. The effect of switching httpDNS for the first time is slightly different (if the implementation plan is to use local DNS first, and only use httpDNS when an exception occurs), the packet capture data is as follows:
The first request for TureServerIp shows that it is the ip 1.2.3.4 configured in the Host and the HeaderHost does not display the domain name, indicating that the domain name access is used without httpDns;
After the access fails, the app will automatically go to HttpDns to obtain the real ip and request the server again
After that, the App will always use IP direct connection
Comparing the app without httpDns and the app with httpDns, the packet capture data HeaderHost and TrueServerIp will be significantly different.