Explanation of DNS principles-network disconnection in six provinces is not related to DNSPod

Recently, I have seen a number of articles on DNS faults on CB, most of which have errors. The problem is due to DNSPod, which is the illusion of innocent victims. Here I think it is necessary to say that DNSPod is an innocent victim, and all the errors are in the storm (and hackers ). First, let's talk about how DNS is registered:

After a domain name is successfully registered, the owner of the upper-level domain name authorizes the resolution of the domain name (Delegate) to the Domain Name Server specified by the user. At this time, the server becomes the Authoritative server of the domain, all queries to this domain name are subject to the results provided by this server. (The NS record is not authorized .)

For example, after Sina registers sina.com and pays VeriSign money, VeriSign adds the following records to their Root Domain Name Server:

Sina.com. 60 in ns ns3.sina.com.cn.
Sina.com. 60 in ns ns1.sina.com.cn.
Sina.com. 60 in ns ns2.sina.com.cn.
Ns1.sina.com.cn. 37305 in a 202.106.184.166
Ns2.sina.com.cn. 37305 in a 61.172.201.254
Ns3.sina.com.cn. 37305 in a 202.108.44.55

Then let's look at how to parse:
Because DNS is a very basic service that directly affects the efficiency of network access, it uses multi-level caching. After a program sends a DNS request, the system first searches for its own DNS Cache. If no DNS cache is found, the system sends a request to the DNS server in the network settings. For a telecom user, the server is automatically configured as a designated server by the DHCP protocol.

After receiving the request, the DNS server of China Telecom checks its own cache. Unlike the cache mechanism of personal computers, the public DNS server generally reduces traffic to speed up resolution, the maximum time specified in a successfully resolved Domain Name Record (that is, the TTL value, typically 3600 seconds ). However, if there is no record for this domain name in the cache, there are two options based on the configuration: one is to request (Forwarder) from your superior DNS server ), second, start from root-hints step by step. For example, when you receive a request from www.sina.com, DNS finds that there is a cache. com domain name NS (Domain Name Server pointing to) records, then request sina.com to the server, get a Sina domain name NS records, and then request www.sina.com to the server. Sina's server returns the result, parses the result successfully, returns the result to the user, and caches all the intermediate results for future use.

From the above process, we can see that most of the domain names frequently accessed by users are already in relatively low-level DNS cache. Generally, requests are sent to the authoritative server of the domain name several hours.

Let's take a look at this network disconnection event:
DNSPod was first attacked. In fact, DNSPod Web servers (and NS1) were also attacked a few days before the network disconnection. Because of the huge traffic, the local telecom has blocked the IP address of their main domain name server on the backbone network.

After 3600 seconds, the records of storms cached on DNS servers in various regions expire, but the NS records directed to DNSPod by the storm have not expired (generally 24 hours ), as a result, DNS in various regions continue to send queries to servers with blocked IP addresses. Because the UDP protocol is used for domain name query, the server does not immediately realize that the host of the other party has been taken offline (or may also be related to the method of the electronic envelope IP address, and does not return an ICMP packet), and does not give up the query after the timeout. However, because the DNS server is generally configured as a query that fails to be cached, when the next DNS request comes, it still has to send a query to the blocked IP address.
(Note that the IP address of DNSPod is enveloped, and all subsequent content is irrelevant to DNSPod .)

Then let's take a look at what the storm client is doing. First, it "requests an advertisement or upgrade from its own server innocently", so it needs to resolve the Domain Name of the server. After receiving the request, the DNS server of China Telecom waits for two seconds but fails to receive the result, so it has to say sorry to the client. However, the storm client immediately began to retry and try again, so hundreds of millions of storm users in the country sent requests to the DNS server. As these servers cannot resolve domain names, these requests are gradually accumulated in the memory. The worst thing is that each request requires a request ID corresponding to each client, and the number of IDS is limited. When the number of concurrent requests reaches a certain number, the memory or ID is exhausted, the server has rejected the service.

From the above, we can see that apart from the first hacker to attack DNSPod, the culprit is probably a storm-like program design.