How to verify if domain name resolution is successful? A tutorial on using the nslookup/dig commands!

　　After configuring domain name resolution, how do you confirm it's truly effective? This question is far more complex than it sounds—being able to open a website in your browser doesn't guarantee correct resolution; being able to ping a website locally doesn't mean users worldwide will resolve to the correct IP address. The most reliable way to accurately verify domain name resolution status is to use a DNS diagnostic tool directly, rather than relying on a browser or ping.

　　nslookup and dig are the two core command-line tools for DNS troubleshooting. nslookup is more interactive and readable, comes pre-installed on both Windows and Linux, and has a low learning curve. dig provides more detailed output, closer to the protocol's underlying layer, making it the preferred choice for professional system administrators. Both tools have their strengths, but both answer the same question: what exactly a domain name resolves to on a particular DNS server?

　　Let's look at nslookup first. This is the most basic usage, directly querying the system's currently configured default DNS server: nslookup example.com. The output will display the DNS server address and the IP address corresponding to the domain name. If it returns "Non-existent domain," the domain name does not exist; if it returns "Server failed" or "Connection timed out," the DNS server itself has a problem. The default query returns an A record (IPv4 address). To query other record types, use the `-type` parameter: `nslookup -type=AAAA example.com` queries IPv6, `nslookup -type=CNAME example.com` queries aliases, `nslookup -type=MX example.com` queries mail exchange records, `nslookup -type=TXT example.com` queries text records, and `nslookup -type=NS example.com` queries authoritative name servers. These different record types serve completely different functions; choose the appropriate type based on your actual needs during verification.

　　nslookup also has a very useful function: specifying a DNS server for querying. By default, nslookup uses the DNS in your local network configuration, but you might suspect that your local DNS is caching old records. In this case, you can bypass your local DNS and directly query an authoritative server or public DNS: `nslookup example.com 8.8.8.8`. This command will cause Google's public DNS to resolve the record. If the returned IP is different from the default query, it means that your local DNS may still have an outdated cache. Furthermore, if you want to directly query the authoritative server, first use `nslookup -type=NS example.com` to get the domain name of the authoritative server, then use `nslookup example.com authoritative server IP` to bypass all intermediate caches and directly view the actual DNS records stored on the authoritative server. This operation is particularly useful when troubleshooting DNS resolution delays.

　　nslookup also has an interactive mode. Simply type `nslookup` and press Enter to enter the interactive environment, where you can execute multiple query commands consecutively. This is suitable for batch troubleshooting or repeatedly testing different record types. Use `exit` to exit. However, it's important to note that nslookup does not automatically trace the chain when querying CNAME records; it only returns the first-level name and does not tell you what the final A record it points to is.

　　dig is more commonly used on Linux systems. Its output format is more rigorous than nslookup and is more suitable for script processing. The most basic usage is `dig example.com`, and the returned results are divided into several parts: the HEADER section displays the query metadata, including opcode, status, and flags. The status field shows NOERROR if the query was successful, NXDOMAIN if the domain does not exist, SERVFAIL if there is an internal server error, and REFUSED if rejected. The QUESTION SECTION displays the query question, and the ANSWER SECTION contains the core answer. If the query is for an A record, this is the IP address; if zero answers are displayed, the record does not exist. `dig` defaults to querying A records. To query other types, use `dig example.com AAAA`, `dig example.com MX`, `dig example.com CNAME`, `dig example.com TXT`, and `dig example.com NS`.

　　The most powerful feature of `dig` is its ability to precisely trace the DNS resolution chain. Using the +trace parameter: `dig +trace example.com`, this command will start from the root name server, querying the root server, top-level domain server, and authoritative server step by step, showing the entire DNS resolution process. The server address and response time returned at each level are displayed, clearly showing which step the resolution is stuck at. If an intermediate step returns a timeout or rejection, the problem is immediately apparent. This feature is more intuitive than any other tool when troubleshooting cross-domain resolution issues or authoritative server configuration errors. Another commonly used parameter for `dig` is `+short`, which outputs only a simplified result, displaying only the IP address without any other information, suitable for use in scripts: `dig +short example.com`. To specify a DNS server for querying, use the `@` symbol: `dig @8.8.8.8 example.com`, which queries the Google DNS resolution results. `dig @authoritative server IP example.com` bypasses all caches and retrieves the original record from the authoritative server.

　　In actual operation and maintenance, verifying whether domain name resolution is successful is not a single command matter; it requires layered verification.

　　The first layer verifies whether the record on the authoritative server is correct: `dig @authoritative server IP example.com`. If the IP returned in this step matches your expectations exactly, it means that your DNS service provider's configuration is correct.

　　The second layer verifies whether the public recursive DNS can correctly retrieve this record: `dig @8.8.8.8 example.com`. This step determines whether the resolution result has been correctly synchronized to the public internet.

　　The third layer verifies the local network's DNS cache status: `dig example.com` (without any DNS parameters). If the returned result is consistent with the previous two steps, it means that the local DNS has also been updated correctly.

　　If all three layers pass, it means that the resolution is working correctly globally. If an inconsistency occurs at any step, you need to locate the problem based on which layer it is stuck at: an error returned by the authoritative server indicates that the record itself is misconfigured; a failed public DNS query indicates that there may be a problem with the NS record between the authoritative server and the top-level domain; an old value returned by the local DNS indicates that the cache has not expired, and you should wait for the TTL to expire or manually refresh the local cache.

　　When the resolution points to the correct IP but the website is inaccessible, you can use `dig` to verify whether the certificate domain name matches: `dig example.com` returns an IP address that matches the Common Name or SAN entry in the SSL certificate. If they do not match, the browser will report a certificate error. You can also use `dig` to troubleshoot email sending failures: `dig MX example.com` confirms the mail server address is correct, and `dig TXT example.com` checks if the SPF record allows the sender's IP address; many rejected emails are due to incorrect SPF configuration. Additionally, both `nslookup` and `dig` can be used in IPv6 environments. Querying AAAA and A records follows the same logic; you just need to specify the record type as AAAA.

　　The differences between the two tools are also worth mentioning. `nslookup` is interactive, with highly readable output, suitable for beginners to quickly view information, but its capabilities are limited when handling complex DNS record chains and tracing resolution paths. `dig` is designed for professional scenarios, with standardized output format, complete information, and is suitable for large-scale automated operations and maintenance, but it is not included by default on Windows and requires separate installation. If you are performing temporary troubleshooting on Windows, `nslookup` is sufficient; if you are maintaining a production environment on a Linux server, `dig` is an essential tool. Many system administrators are accustomed to using ping to verify DNS resolution, but ping itself uses the ICMP protocol, which is not entirely equivalent to DNS resolution. Furthermore, ping doesn't tell you exactly which IP address the domain name resolved to; it only implicitly calls the system's DNS resolution library. To truly confirm the resolution result, you must use nslookup or dig for explicit lookup. Additionally, browsers are not suitable as verification tools because they have their own DNS cache, HTTP cache, HSTS lists, and may even be in a proxy environment, all of which interfere with pure DNS resolution results. Only the answers provided by command-line tools are accurate and unaffected by the client environment.

　　Finally, here's a practical tip: After changing the DNS settings, you can execute the command `watch -n 1 dig +short example.com` to have dig output the IP address every second. Watch the screen and see the moment the IP address jumps from the old value to the new value; that instant is when the DNS resolution truly takes effect globally, which is more direct than any graphical monitoring interface. Similarly, on Windows, you can manually execute `nslookup example.com` continuously to observe the changes in the returned results. Once you've mastered the basic usage of nslookup and dig, domain name resolution will no longer be a black box for you. What it does, what step it's at, and where it gets stuck are all written in the command output. Learning to read this output is more useful than memorizing a hundred troubleshooting tips.