1.
The RequestDNS sent by the client was not received by the server;
2.
The server received the RequestDNS sent by the client, but did not respond;
3.
The server received the RequestDNS sent by the client and returned the result, but the client did not receive the response back;
1.
When the client sends Request, the router and other devices lose packets due to local network congestion.
2.
The client did not arrive at Request due to fluctuations in the network environment (for example, zone Network fluctuated)
3.
There is packet loss from an intermediate device on the Network link.
The second situation can be divided into the following possible reasons:
4.
The DNS server has received it and will discard some Request when the load is too high, because the number of DNS processes at the same time is limited.
5.
If the checksum of the UDP protocol (Network layer) does not match, the DNS server will not respond.
The third situation is similar to the first situation, but in reverse
----------------------------------------Separating line------------------------------------------------
When answering customers' questions such as "Why can't it be parsed?" or "Whose problem is this?" it is recommended to check and answer like this:
6.
Answer first: The failure to resolve is caused by the DNS server not responding to the IP. The specific reasons are more complicated. We will first confirm the quality of Probe.
8.
If the phenomenon is for a single Probe, first filter and check the errors in the Probe task execution records (the time range can be extended to 7 days). If there is no problem, reproduce the error with Instant Testing. If it reappears, the Probe is more likely to be the cause. Submit a case to the backend. If it does not reappear, the Probe has no issue. (reproduce several times)
9.
If it is a scope problem, first filter out Error Probe, and then see if it uses the same DNS (because you must first confirm whether the DNS is officially pushed), and then see if Probe IP is a C segment (used to confirm whether it is the Probe of the same person)
10.
If neither of the above two methods can effectively analyze the situation, submit the case to TAM (you must first do the first two steps...)
----------------------------------------Separating line------------------------------------------------
In fact, after submitting the case, the backend will not do anything like Instant Testing for the single point, but:
11.
Directly search for the data of all tasks performed by Probe in the recent period and analyze the proportion of Error;
12.
Then search for the "suspected DNS server" that is used to perform all tasks of IP resolution, and check the resolution Error ratio of this DNS.
