Why does mobile need HTTPDNS?

If you can only answer that in case webViews are hijacked by domain names, then this is a good article to read. This article will examine several aspects of why HTTPDNS is necessary for mobile apps.

Let’s review how DNS works

To understand why mobile apps need HTTPDNS, first understand the principle of DNS, know how DNS works, and what the problems are, to analyze the advantages of HTTPDNS.

DNS working mode:

1. Enter www.taobao.com on a PC. The PC sends a DNS request to the local DNS server.

Basically, a local DNS server is a local DNS server that your network provider, such as China Telecom, has set up near you without special Settings

2. After receiving this request, the local DNS server of China Telecom will check its cache table. If taobao.com is found in the cache table, it will directly return the IP address; if not, it can only search the root DNS server. Note that there are only 13 root DNS servers in the world, which are not responsible for resolving DNS requests. This means that these 13 servers will not directly tell you the IP address of the domain name, but will tell you where to find it

3. When the root DNS server receives the request, it tells you to go to the top-level DNS server. The top-level DNS then tells you to go to the authoritative DNS server responsible for Taobao.com. The authoritative DNS server is usually a big top web site will put one, so it is called authoritative DNS server, after all, you can resolve your own authoritative DNS server, so eventually the authoritative DNS server will tell the IP address of the local DNS server near your home, And then the local DNS server returns an IP address that tells your computer what the IP address of that domain name is.

Does DNS only return IP addresses?

Probably for most client development, the understanding of DNS is simply a function of finding IP by domain name. But DNS does much more than that. DNS can even do load balancing. Remember our authoritative DNS server? This place can do a load balancing function, the simplest, after receiving DNS requests, evenly allocate different IP addresses. Or even return an optimal IP address to the local DNS. An optimal IP address is, of course, the one closest to your home.

What are the shortcomings and problems of DNS?

1. Cache invalidation. For example, I once ate KFC in Nanjing South Railway Station. If I still want to eat KFC when I get to this position in Nanjing Station, I will of course choose KFC near Nanjing South Railway Station. No one will choose to eat KFC in Nanjing South Railway Station again. Local DNS servers have this problem.

This happens when his cache is not updated in time. Sometimes he will even deliberately configure a wrong IP, used for carrier hijacking.

2. The carrier is lazy in forwarding DNS requests. This is also a common problem for mobile terminals. For example, when the base station of China Mobile finds that the pressure is too great at this time, he will be lazy and forward the DNS request to China Unicom. Then China Unicom will query your authoritative DNS server after some operation. Your authoritative DNS server gives you a Unicom IP address because it thinks you are a Unicom user, but in fact you are a mobile user. Your subsequent visits will slow down the interface response due to carrier cross-domain issues.

3. It’s even worse for wifi users at home. We all know that the address we use to access the Internet at home is the so-called Intranet address, and we access the outside world through the NAT service provided by the carrier. That is to say, when we access the Internet at home, the carrier will translate our Intranet address into an Internet address that connects to the Internet. This process is called NAT. NAT on the pit daddy, he translated the address is not fixed, this will lead to our authoritative DNS server mistake, for example, you are clearly China Mobile broadband user, after NAT, authoritative DNS will think this is unicom user, and returned a Unicom IP node… Here have to ridicule the Great Wall broadband, NAT out of the address of the country floating.

4. Dr Cannot be performed. For example, I have a server whose IP address is 1.2.3.4 that is down. When my authoritative DNS server finds this problem, I update the IP address to 1.3.5.7, so that new DNS requests will not access 1.2.3.4. The problem is, where are the old users? No one knows the update frequency of the carrier’s local DNS server, so how to do Dr For this server? Can’t do

If the local DNS fails to find the IP address of the domain name, it will go a long way to search for the corresponding IP address. If the signal is unstable, the recursive search for the IP address may time out or even fail.

In general, DNS is faced with these problems, and it can be seen that these problems are fatal to mobile apps. Even without DNS hijacking causing mobile webViews to display strange ads, these experience and technical issues are not allowed. That’s why we have HTTPDNS to solve these problems.

How does HTTPDNS solve this problem?

HTTPDNS for those who are still new to HTTPDNS, you can go to Alicloud to play this HTTPDNS, there are ready-made Android or ios demo. It will not be repeated here. A quick overview of how HTTPDNS works.

1. After receiving a DNS request, the SDK of the client queries the IP address on the HTTPDNS server. The mapping between the domain name and IP address is saved locally.

This is a place where you can see that the cache is controlled by the SDK itself regardless of the carrier. Since it is their own control there is no domain name hijacking, cache update is not timely and other problems.

2. Because the DNS query process is to send an HTTP request to the HTTPDNS server, the whole process is controllable, so our HTTPDNS server of course know your phone situation, where you are, you are which carrier can get your information naturally can return you the most appropriate IP.

Avoid the old DNS phenomenon of returning inappropriate IP addresses. This load balancing is almost perfect.

3. Old-school DNS parsing, if the cache takes too long to recursively query, we can do it with a single HTTP request. Too fast

4. The SDK’s DNS local cache policy is a matter for you to discuss with the server. Precise and controllable, choose a cache strategy that works best for you.

Finally, even if you use HTTPDNS also do a downgrade scheme, in case HTTPDNS fails we can still go to the old DNS, slow is better than a total site failure