It is found that the problem occurs not in the same Probe, but in a relatively high proportion. The reason cannot be found from the report, so it needs to be analyzed from the packet capture. From the packet capture below, you can see that the client has been performing DNS resolution for the first 13 seconds, almost once a minute, and the resolution is not successful until nearly 14 seconds. Before that, the server has not responded.
(1) First rule out whether it is the Probe problem, Instant Testing reappears (2) After eliminating the Probe problem, provide the corresponding screenshot to the customer. If it is an operator customer, the customer needs to find the corresponding DNS to check the log to see why there is no response; if it is a non-operator customer, the customer needs to contact the corresponding operator to analyze and find the reason.
How DNS works: Step 1: The client proposes domain name resolution Request and sends the Request to the local domain name server. Step 2: When the local domain name server receives Request, it first queries the local cache. If there is such a record, the local domain name server directly returns the query result. Step 3: If there is no such record in the local cache, the local domain name server will directly send Request to the root domain name server, and then the root domain name server will return to the local domain name server the address of the primary domain name server of the queried domain (subdomain of the root). Step 4: The local server sends Request to the domain name server returned in the previous step, and then the server that accepts Request queries its own cache. If there is no such record, the address of the relevant lower-level domain name server is returned. Step 5: Repeat step 4 until the correct record is found. Step 6: The local domain name server caches the returned result Save for next use and returns the result to the client. There is no second step when Tingyun is a client, because the client cache will be cleared before each task.