Demystifying DNS Resolution
When you open a web browser and type google.com, your computer does not inherently know where that website lives. It must ask a Domain Name System (DNS) server to translate that human-readable domain name into a machine-readable IP address (like 142.250.190.46).
Usually, this happens instantly and invisibly. But what happens when a website suddenly stops loading? Is the web server down, or is your internet service provider’s DNS server failing to resolve the address correctly?
To diagnose DNS issues directly from the Linux terminal, system administrators rely on the dig (Domain Information Groper) command. It is the most powerful tool available for querying DNS name servers and understanding exactly how internet traffic is being routed.
Step 1: The Basic DNS Query
The most common use of dig is simply asking: “What is the IP address for this domain?”
Open your terminal and type:
dig google.com
The output will contain a lot of technical metadata, but the most important section is the ANSWER SECTION. It will look something like this:
;; ANSWER SECTION:
google.com. 210 IN A 142.250.190.46
This tells you that the “A record” (Address record) for google.com currently points to that specific IPv4 address. If the answer section is completely empty, you immediately know there is a DNS resolution failure.
Step 2: Cleaning Up the Output (+short)
If you are writing a bash script and only want the IP address—without the massive block of metadata, query times, and server details—you can use the +short flag.
dig google.com +short
This will output only the raw IP addresses, making it perfect for piping into other commands or log files.
Step 3: Querying a Specific DNS Server
By default, dig uses the DNS server configured by your local network (usually provided by your ISP or router).
If a website isn’t loading, you might suspect your ISP’s DNS is broken or actively censoring the domain. You can force dig to bypass your local network and ask a specific, public DNS server instead.
You do this by adding the @ symbol followed by the IP address of the server you want to interrogate.
To ask Cloudflare’s public DNS (1.1.1.1):
dig @1.1.1.1 google.com
To ask Google’s public DNS (8.8.8.8):
dig @8.8.8.8 google.com
If your local query fails, but the Cloudflare query succeeds, you know definitively that your local DNS is the source of your internet outage.
Step 4: Finding Mail Servers (MX Records)
DNS does not just handle website IPs. It also directs emails. If you want to know which company handles the email routing for a specific domain, you query its MX (Mail Exchange) records.
dig digitash.com MX
The answer section will list the mail servers. If it returns aspmx.l.google.com, you know that company uses Google Workspace for their corporate email. This is incredibly useful for IT auditing and troubleshooting email delivery failures.
Step 5: Tracing the Full DNS Path (+trace)
When you query a domain, your DNS server usually just hands you the cached answer. But how did it get that answer originally?
DNS is hierarchical. The root internet servers point to the .com servers, which point to the specific company’s name servers, which finally provide the IP address.
To force dig to show you this entire, step-by-step resolution path from the very top of the internet down to the final IP, use the +trace flag.
dig google.com +trace
This will bypass all local caches and show you exactly where the DNS request is being routed across the global internet. If a website’s domain registration just expired, or if their name servers are misconfigured, the +trace output will show you exactly where the chain breaks.