Unable to Resolve Server Name or Address (3)

Scenario 1: There is a client query record, but there is no DNS server response record
Step 1: Obtain the scatter point details link of the error report
Step 2: Open the scatter point details link and obtain the corresponding captured packets

It is found that there is no packet capture item in ProfilingLog, indicating that packet capture is not enabled for this task. In this case, you can specify the Probe to reproduce Instant Testing (the recurrence of this type of Error is usually monitored again using the Probe ID (Probe ID) that reported the error and specifying the corresponding DNS). It can be found that the analysis still fails after reproducing.

Step 3: Packet capture analysis (unable to parse the packet information related to the DNS protocol in the Error corresponding analysis packet capture)
Commonly used filtering rules for DNS protocols:

DNS (filter all packets related to DNS protocol)

DNS.qry.name contains "domain name" (filter only contains the DNS resolution related information of the domain name. The domain name is filled in with the domain name in the corresponding monitoring URL. If the task has settings specified hosts-CNAME mapping, in this case, the domain name there is filled with the CNAME of settings)

From the packet capture-packet list information, we can see that the client "10.99.0.101" continues to send Request parsed by the A record to the DNS server: 123.30.175.82, 103.199.16.139, but the server has not responded.
Step 4: Instant Testing result (reproduction)
First, check whether the resolution failure is caused by a DNS server failure. For foreign Probe, we can specify the public DNS server provided by Google: 8.8.8.8 (domestic Probe generally specifies 114.11 4.114.114) Looking at the parsing situation, we found that the 8.8.8.8 server also did not respond. In this case, we can basically judge that it is caused by our Probe itself network exception (local DNS: 103.199.16.139123.30.175.82 and public DNS: 8.8.8.8 both resolve Exception).

Step 5: Solution

task settings-Probe filtering - exclude the following monitoring Probe: press Probe ID (recommended) or Probeip (not recommended) to exclude the corresponding Probe

Temporarily disable the background first, and then unblock the Probe with this error type after subsequent testing and parsing is normal.

Scenario 2: There are client query records and DNS server response records, but there are error messages (Refused, Server failure) in the responses.
Step 3: Packet capture analysis (unable to parse the packet information related to the DNS protocol in the Error corresponding analysis packet capture)

First understand what the Refused and Server failure returned by the DNS server represent.
Server failure indicates a server failure. Generally, it is due to the DNS server itself that it is temporarily unable to process the resolution Request.
Refused means that the resolution is refused. Generally, the DNS server refuses to respond due to the set policy. For example, the server does not want to respond to some Request users.

Step 5: Solution

When Server failure occurs, we can understand that it is the fault of the DNS server itself that cannot respond to the resolved Request normally. In this case, we can first observe the subsequent resolution of the DNS. If Exception continues to be parsed, it will be reported back to the member corresponding to Probe to change the DNS or directly disable the DNS from the background.

When Refused appears, we can understand that the DNS server refuses to resolve the domain name Request initiated by some IPs. This situation is currently based on the fact that the responder cannot find the root cause of the refusal, so we can only avoid this type of problem by excluding it from the task settings or disabling the initiator's IP in the background.