How to optimize your network- DNS domain name resolution service

1. Domain name resolution service
When a device accesses the IoT platform by accessing a specified domain name and port, the first problem encountered is the DNS resolution of the domain name of the access server.
A domain name (Domain Name) is an identifier of a computer or a group of computers on the Internet consisting of a series of names separated by dots. Its purpose is to facilitate people to access services on the Internet more simply and conveniently. In the actual system implementation, the domain name is converted into the IP address of the server through the DNS (Domain Name System) system, so as to facilitate the addressing and communication of the machine through IP. The above behavior, we call it domain name resolution (Domain Name System).

recursive query
If the local domain name server inquired by the client does not know the IP address of the queried domain name during recursive query, then the local domain name server will continue to send queries to other top-level domain name servers as a DNS client until the query results are obtained, and then go to the next level. The layer is passed back.


iterative query
If the local domain name server queried by the client does not know the IP address of the queried domain name during iterative query, the list of domain name servers at the next level will be notified for the client to query.


actual scene
In fact, during the DNS query process, the local DNS server will act as an iterative query on behalf of the client. However, the local DNS does not have the right to determine the domain name resolution results, and only acts as a proxy for the user to obtain the domain name resolution results from the authoritative DNS. There is a caching module on the local DNS. When the target domain name has a cached resolution result and the TTL has not expired, the local DNS will return the cached result. Otherwise, the local DNS will iteratively query the authoritative DNS of each domain name level by level until the final complete domain name is obtained. analysis results. At the same time, the client will also make a cache mechanism based on the TTL value, which can reduce the number of queries and speed up the domain name resolution process.

Let's take access to pk.iot-as-mqtt.cn-shanghai.aliyuncs.com as an example. A complete domain name resolution process includes:

1. The device terminal initiates a domain name resolution request to the local DNS;
2. After the local DNS obtains the domain name resolution request, it first obtains the address of the root domain name (.) server from Root hints;
3. After obtaining the address of the root domain name server, the local DNS initiates a DNS resolution request to the root domain name server;
4. The root domain name server returns the top-level domain name (.com) server address;
5. Then the local DNS initiates a resolution request to the top-level domain name (.com) server, and obtains the address of the second-level domain name (aliyuncs.com) server;
6. The local DNS initiates a resolution request to the secondary domain name (aliyuncs.com) server, and finally obtains the IP address information of pk.iot-as-mqtt.cn-shanghai.aliyuncs.com;
7. The local DNS caches the IP address information obtained by recursive query according to the TTL and returns it to the device terminal;
8. The device terminal initiates a network request to the destination IP;

2. DNS domain name resolution experiment

2.1 DNS domain name resolution
If you want to access the domain name pk.iot-as-mqtt.cn-shanghai.aliyuncs.com, you must first find out its IP address is 139.196.135.135 through DNS.
We can use the dig command to view the IP list corresponding to the domain name, as follows:

The figure above shows the current mac computer obtains the IP list of the domain name from the local DNS server, and the TTL value (Time to live) is 18s.


2.2 The complete process of DNS resolution
The DNS server conducts hierarchical queries according to the domain name levels, that is, starting from the root domain name, it queries the NS records of each level domain name in turn until the final IP address is found. The process is roughly as follows:

1. Find the NS record and A record (IP address) of the "top-level domain name server" from the "root domain name server"
2. Find the NS record and A record (IP address) of the "secondary domain name server" from the "top-level domain name server"
3. Find out the IP address of the "host name" from the "secondary domain name server"
Among them, each level domain name has its own NS record, and the NS record points to the domain name server of this level domain name. These servers know various records of the next-level domain names.
We can understand the complete parsing process through dig +trace, as follows:

The figure above shows the complete process of DNS,

1. First, the Mac computer obtains the root domain name (.root) server list from the local DNS server,
2. Secondly, obtain the top-level domain name (.com) server list from one of the root domain name servers (198.41.0.4)
3. Obtain the server list of the second-level domain name (aliyuncs.com) from one of the top-level domain name servers (192.48.79.30) again
4. Finally, the IP list of the target domain name was obtained from one of the secondary domain name servers, with a total of 3 IP addresses

3. DNS resolution in IoT scenarios

3.1 Potential problems in domain name resolution
When we understand the complete process of DNS domain name resolution service, we will find the following problems in traditional domain name resolution:

domain hijacking
Domain name hijacking has always been one of the problems that plague many developers. Its manifestation is that the DNS resolution result IP1 that should be returned by domain name A is maliciously replaced by IP2, resulting in A's access failure or access to an unsafe site.

Inaccurate scheduling
In addition to the problem of domain name hijacking, domain name resolution based on traditional Local DNS will also bring about the problem of domain name scheduling accuracy. For scenarios such as CDN domain name access that require intelligent resolution and scheduling by region and operator, the demand for precise scheduling is very strong.

Analytic validation lag
In some business scenarios, developers are very sensitive to the effective time of domain name resolution changes (this part of the change operation is completed by the developer on the authoritative DNS). For example, when the business server is attacked, we need to switch the business IP to On another group of clusters, such demands cannot be fulfilled under the traditional domain name resolution system.

large delay
For the first DNS query or the query after the cache expires, it is necessary to recursively traverse multiple DNS servers to obtain the final resolution result, which increases the lead delay time of network requests. Especially in the mobile Internet scenario, the quality of the mobile network is uneven, and the RTT time in a weak network environment may be as high as hundreds of milliseconds. For an ordinary service request, the above delay is a very heavy burden. On the other hand, resolution timeouts and resolution failures are common in weak network environments. How to reasonably optimize DNS resolution is crucial to improving the overall network access quality.

3.2 Alibaba Cloud HTTPDNS service
Alibaba Cloud's HTTPDNS service came into being under such a background, providing us with a safer, more stable and more efficient recursive DNS service and proxying the process of domain name resolution.

HTTPDNS uses the HTTP protocol for domain name resolution, replacing the existing UDP-based DNS protocol. Domain name resolution requests are sent directly to the HTTPDNS server, thereby bypassing the operator's local DNS, and delivering the end user's IP information directly to the authoritative DNS, avoiding local Due to the interference of DNS coordinates, the analysis results changed by users in the authoritative DNS will be quickly synchronized to HTTPDNS, covering the original cache records, and helping users to achieve second-level domain name resolution switching.


3.3 DNS Actual Combat in IoT Scenarios
However, after we create a product on the IoT platform console, the corresponding device will be generated to access the specified domain name, as shown in the following figure:


Next, we need to add the domain name resolution service for accessing IoT devices to the HTTPDNS console, as shown in the figure below:


Then, obtain the IP list of the device access domain name by directly accessing the IP of HTTPDNS, refer to the following figure:

Finally, the IoT device can directly access an IP in the IP list, and establish an MQTT long connection channel with the IoT platform.