When encountering DNS poisoning, cache poisoning, replay attacks, or traffic amplification attacks, DNS logs are the most critical evidence and basis for problem localization. Many operations and maintenance personnel often overlook the DNS dimension when troubleshooting network anomalies. However, in-depth analysis of DNS Query, Response, Flags, Rcodes, TTL, and Upstream information can often accurately determine the source of pollution, attack type, and potential security risks. The core of using DNS logs for troubleshooting is to establish a "normal behavior baseline," and then locate the problem from abnormal query patterns, abnormal return IPs, response latency jitter, changes in query source distribution, and protocol parameter offsets. The log formats differ slightly across different DNS resolution architectures, but the analysis logic is common.

　　When analyzing DNS poisoning, the first focus is usually on the reliability of the returned results. If a request returns an A record or CNAME from an unexpected IP range, even if the query is successful, it is highly likely that the link has been poisoned. For example, if a user should access 172.67.xx.xx, but the logs show unfamiliar addresses like 37.xx.xx.xx or 203.xx.xx.xx, and the TTL is abnormally short or long, it may indicate that a forged response has been forcibly inserted into the DNS resolution link. Common poisoning techniques include UDP-based local injection, ISP outbound interference, and cross-border link hijacking. These all leave typical characteristics: the same query is answered multiple times within a short period, the AD bit is missing in the Flags, unexpected appearance of forged SOA information in the Authority Section, abnormally small or large response size, and DNSSEC verification failure. Therefore, retrieving abnormal IPs or abnormal TTLs from the logs is crucial for locating poisoning.

　　A typical log analysis process can begin by recording the internal query/response behavior of the DNS server. Below is an example of query records typically output by CoreDNS or Bind:

28-Nov-2025 11:21:35.123 client @0x7fbdc8000abc 192.168.1.10#52768 (example.com): query: example.com IN A +E (192.168.1.53)
28-Nov-2025 11:21:35.226 client @0x7fbdc8000abc 192.168.1.10#52768 (example.com): reply: example.com IN A 159.223.xx.xx 300

　　If contamination occurs, the log may show the following:

28-Nov-2025 11:21:35.223 unexpected answer example.com A from 37.xx.xx.xx, TTL=5, QR=1, AA=0, AD=0

　　Forged responses typically have a very low TTL (e.g., 1, 5, 10) and the DNSSEC AD flag is 0. Link-layer injection can be directly identified by comparing the TTL returned by the real authoritative server.

　　If the goal is to investigate cache poisoning attacks, focus on the consistency of cache write logs within the DNS server and random ports and query IDs. Attackers attempt to preemptively return data from the real authoritative server by forging responses, resulting in momentary duplicate response conflicts with the same query ID and domain name in the logs. Bind will output something like:

named[1528]: validation failure <api.example.com A>: unexpected answer from 203.xx.xx.xx
named[1528]: error (unexpected RCODE SERVFAIL) resolving 'api.example.com/A'

　　If you continuously see verification failures, unexpected answers, or bad cache entries, you should check if the random port is fixed, if DNSSEC is enabled, and if 0x20-bit obfuscation is enabled as part of your defenses.

　　When a DNS server is under a DoS or DDoS attack, the log patterns change significantly. The QPS (Queries Per Second) will spike rapidly within a short period, with the vast majority of requests originating from random IPs, and the queries primarily consisting of non-existent subdomains, large TXT records, or ANY queries. For example, an attacker might construct the following behavior:

random12345.example.com ANY
dkfjskdfj11.example.com TXT

　　The logs will show a large number of NXDOMAIN or REFUSED responses, along with a spike in CPU usage and increased latency. If the recursive server is being exploited, the following may also occur:

large response size 3500 bytes sent to spoofed IP

　　This means that attackers use requests with spoofed source addresses to amplify your DNS server.

　　When investigating DNS-level attacks, it's also necessary to analyze anomalies based on the distribution of source IPs. Normally, user traffic originates from a few regions and fixed network segments, while attack traffic exhibits a globally random distribution. If Unbound is deployed, you can use querylog tools to export data and then perform statistical analysis.

unbound-control dump_requestlist
grep "example.com" /var/log/unbound.log | awk '{print $6}' | sort | uniq -c | sort -nr | head

　　If an IP address sends thousands of queries within a minute, or only queries the same subdomain and the same type of records, it can generally be identified as malicious probing or a DoS attack.

　　For link-layer DNS poisoning, tcpdump can be used for verification, because forged responses often "beat" the real authoritative server and return a response before it does.

tcpdump -nvvv -i eth0 port 53 and host example.com

　　If a response from an unfamiliar address is found before the genuine authoritative server returns, and the Query ID is the same, this is a typical case of local injection pollution.

　　If the DNS server has DNSSEC deployed, the log information about verification failures is extremely valuable. DNSSEC can identify all unsigned forged responses, so polluting a link often results in errors such as SERVFAIL, verification failure, and signature expiration. Users may think the website is inaccessible, but the real reason is that the link is poisoned and DNSSEC is blocking the response. The logs will show:

dnssec: signature validation failed for example.com RRSIG: bad signature

　　This is strong evidence used to determine if contamination exists.

　　When investigating CDN-related domain name resolution anomalies, it's also essential to compare the results returned by different upstream or public DNS servers. If an operator's exit point in a certain region is contaminated, user resolution will be redirected to incorrect IPs. Log analysis can verify the following aspects: whether the responses from different recursive servers are consistent, whether the same query returns specific black hole addresses in a certain region (usually common contaminated IPs such as 37/8, 45/8, 109/8, etc.), whether the TTL is consistent, and whether there is packet loss or timeout. The following log patterns are particularly alarming:

query timed out to 8.8.8.8#53
unexpected RCODEnxdomain from 114.xx.xx.xx

　　This means the upstream DNS has been compromised.

　　After initial analysis, an analysis chain needs to be established to pinpoint the source of the incident. If the contamination occurred on the local network, check if the router is infected, if DNS hijacking is occurring, or if it is being forcibly forwarded to port 53. If the contamination occurred at the ISP level, switch to DoT/DoH or use an encrypted tunnel. If it's an attack, implement rate limiting, enable response policies, disable any queries, enable RRL, and enable DNS cookies.

　　Finally, the core capability of using DNS logs to investigate contamination and attack incidents lies in identifying abnormal patterns from massive amounts of data, building baselines, and inferring the source of the problem by combining link characteristics. DNS logs are not isolated data; they need to be combined with network packet capture, server resource monitoring, and results returned by external public DNS to complete the full chain of events. With mastery of log analysis, DNS is no longer a black box, but a controllable system that can be precisely observed and quickly addressed.