When encountering issues such as inaccessible domains, abnormal access speeds, or inconsistent DNS resolution results, the first step is often not to restart the service, but to check if the DNS resolution records and process are normal. Linux systems provide various tools and methods to help us locate DNS resolution behavior from different levels. Linux does not save a complete "DNS resolution history" by default like web servers. "Checking DNS resolution records" refers more to observing current or recent DNS resolution behavior through system configuration, real-time query tools, cached information, and logs. Understanding this makes subsequent operations clearer.

　　In Linux systems, the core configuration file for DNS resolution is `/etc/resolv.conf`. This is the most basic and important entry point for the system when performing domain name resolution. By viewing this file, you can see which DNS servers the system is currently using and the resolution order. Common methods for viewing this file are as follows:

cat /etc/resolv.conf

　　Or use a method more suitable for reading long documents:

less /etc/resolv.conf

　　In the output, the IP address listed after `nameserver` is the DNS server address that the system requests when resolving domain names. If you find abnormal resolution results, you should first check if this file has been tampered with, especially when using a public network, cloud server, or compromised environment. Sometimes, the root cause of DNS hijacking problems is malicious modification of this file.

　　However, simply checking the DNS server configuration does not directly reflect whether the resolution results are correct. In this case, you need to use a command-line query tool to obtain real-time DNS resolution results. The most commonly used and recommended tool is `dig`. Compared to the traditional `nslookup`, `dig` outputs more detailed information, making it very suitable for troubleshooting.

　　Using `dig` to view the DNS records of a specific domain is very simple, for example:

dig example.com

　　After execution, you will see structured output containing the query time, the DNS server used, the type of record returned, and the final resolved IP address. Pay special attention to the ANSWER SECTION, which shows the actual resolution results returned by the DNS server. If you want to view a specific type of record, such as an A record or an MX record, you can write it like this:

dig example.com A
dig example.com MX

　　In practical troubleshooting, `dig` has another very valuable use: specifying a DNS server for resolution comparison. This is especially important when determining whether the local DNS is poisoned. For example:

dig example.com @8.8.8.8

　　By assigning the same domain name to different DNS servers for resolution, you can quickly determine whether a resolution error originates from your local configuration or an external DNS service.

　　If you prefer a simpler and more intuitive tool, nslookup is also an option. Although it's becoming increasingly marginalized in newer systems, it remains useful in certain environments. For example:

nslookup example.com

　　The output will also display the DNS server address and resolution result. Compared to `dig`, `nslookup` is more suitable for quick verification than for in-depth analysis of the resolution path.

　　Besides active queries, many people are concerned about whether Linux can view already resolved DNS records. This involves the issue of DNS caching. By default, most Linux systems do not cache DNS themselves, but instead hand the requests directly to an external DNS server. However, in some environments, the system enables caching services, such as systemd-resolved, dnsmasq, or nscd.

　　If your system uses systemd-resolved, you can view the currently cached DNS resolution records using the following command:

systemd-resolve --statistics

　　While this command doesn't list all domains directly, it can confirm information such as whether caching is enabled and the number of cache hits. If you want to view the DNS records of a specific domain, you can use:

resolvectl query example.com

　　This command displays the resolution results, the interface used, and the DNS server source, which is very helpful for troubleshooting issues in environments with multiple network cards and multiple DNS servers.

　　And if `nscd` (Name Service Cache Daemon) is running on the system, its status can be checked in the following ways:

nscd -g

　　In the output, you can see statistics about the hosts cache, which can help determine whether DNS is being cached. If there are cache anomalies, clearing the cache is often a crucial step in troubleshooting.

nscd -i hosts

　　In some server or gateway environments, dnsmasq is also deployed as a local DNS caching and forwarding service. If logging is enabled, dnsmasq logs often contain detailed DNS query records. These logs are typically located at:

/var/log/syslog

　　or

/var/log/messages

　　You can quickly filter DNS-related content using grep:

grep dnsmasq /var/log/syslog

　　For scenarios where you want to monitor the DNS resolution process in real time, such as suspecting that the system is frequently requesting abnormal domain names in the background, you can use the packet capture tool tcpdump. DNS uses port 53 by default. The command to capture relevant traffic is as follows:

tcpdump -i eth0 port 53

　　If you want to see more intuitive domain information instead of raw binary data, you can add the following DNS resolution options:

tcpdump -i eth0 port 53 -n

　　This method allows you to see in real-time which domains the system is querying, which is invaluable for security analysis and intrusion detection. However, packet capture requires root privileges and is not suitable for prolonged execution on high-traffic servers.

　　Furthermore, when troubleshooting DNS resolution issues, the `/etc/hosts` file should also be checked. Linux prioritizes querying this file when resolving domain names; if a corresponding entry exists, it will return the result directly without going through DNS. The method for viewing `/etc/hosts` is as follows:

cat /etc/hosts

　　Sometimes, access problems aren't due to DNS server issues, but rather to outdated or incorrect static mappings in the hosts file.

　　Overall, viewing DNS resolution records in Linux isn't a simple task that can be solved with a single command; it's a comprehensive process combining configuration files, query tools, caching mechanisms, and log analysis. Different tools have different focuses: `resolv.conf` confirms the resolution entry point, `dig` and `nslookup` verify the resolution results, caching tools help understand system behavior, and packet capture provides the most fundamental and realistic data perspective.