When DNS problems occur, you need to see what's actually happening rather than guessing based on symptoms. Your website might load fine for you but not for customers. Email might work from some servers but not others. Changes you made hours ago still don't seem to have taken effect. These situations demand a way to query DNS directly and interpret the results.
The dig command (Domain Information Groper) is the standard tool for DNS troubleshooting. While it has dozens of options and can perform complex queries, five basic command patterns handle most situations domain owners encounter. Learning these commands transforms DNS from an opaque system you hope works correctly into something you can actually observe and verify.
Installing dig
Before using dig, you need it installed on your system.
Mac and Linux: dig comes pre-installed on most Unix-based systems. Open Terminal and type dig to verify. If it's not found, install the bind-tools package (Linux) or use Homebrew on Mac.
Windows: dig isn't included by default. Install BIND tools for Windows from ISC's website, or use Windows Subsystem for Linux (WSL) to get a Linux environment where dig is available. Alternatively, several online dig tools provide the same functionality through a web interface if you prefer not to install software.
Online alternatives: If you can't install dig, websites like toolbox.googleapps.com/apps/dig, digwebinterface.com, and others provide web-based dig functionality. The commands and output are essentially the same.
Command 1: Check Your Website's IP Address
The most basic DNS query checks what IP address your domain resolves to. This verifies your A records are configured correctly and helps troubleshoot website connectivity.
What you see in the output:
; <<>> DiG 9.10.6 <<>> example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
example.com. 3600 IN A 192.0.2.1
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 27 10:30:00 PST 2025
Understanding the key parts:
The ANSWER SECTION shows the actual result. Reading from left to right:
- example.com. - the domain you queried
- 3600 - the TTL in seconds (this result will be cached for one hour)
- IN - Internet class (always IN for normal queries)
- 192.0.2.1 - the IP address
Using +short for cleaner output:
The +short option shows just the answer, omitting all the metadata. This is useful when you only care about the final result, not the query details.
Many domains configure both the root domain and www subdomain. Check both to ensure they resolve correctly. If one works but the other doesn't, you've identified a missing DNS record.
IPv6 addresses (AAAA records):
This queries for IPv6 addresses instead of IPv4. If your site supports IPv6, this should return an address. If not, you'll see a NOERROR status but no answer section.
Command 2: Check Email Configuration
Email problems often trace back to DNS configuration. Querying MX records shows where email should be delivered for your domain.
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 mail-backup.example.com.
MX records include priority numbers (10 and 20 in this example). Lower numbers indicate higher priority. Mail servers attempt delivery to priority 10 first, only trying priority 20 if the primary server is unavailable.
The hostname (mail.example.com) is where mail servers should send email for your domain. This hostname must itself resolve to an IP address (via an A record), so you might need to follow up:
Common MX problems revealed by dig:
If your MX query returns no results but you expect email to work, your MX records are missing or misconfigured. If you recently changed email providers, seeing old MX records in results indicates either the changes haven't propagated or you forgot to update them.
Checking email authentication:
Email authentication uses TXT records. Check SPF:
Check DKIM (replace "selector" with your actual DKIM selector):
dig selector._domainkey.example.com TXT
dig _dmarc.example.com TXT
These queries reveal whether email authentication is configured and what policies are in place.
Command 3: Verify DNS Changes Have Propagated
When you make DNS changes, they don't take effect instantly worldwide. Querying specific DNS servers reveals whether your changes have propagated.
Query a specific resolver:
The @8.8.8.8 specifies which DNS server to query. 8.8.8.8 is Google's public DNS. This bypasses your computer's default DNS settings and queries Google's server directly.
Comparing different DNS servers:
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @9.9.9.9 example.com +short
These commands query Google DNS (8.8.8.8), Cloudflare DNS (1.1.1.1), and Quad9 DNS (9.9.9.9). If they all return the same result, your change has propagated to major public DNS servers. If they return different results, propagation is still in progress or caching is causing different servers to have different answers.
Query your authoritative nameserver directly:
First, find your authoritative nameservers:
dig example.com NS +short
This returns nameservers like:
Then query one of them directly:
dig @ns1.example.com example.com
Authoritative nameservers always have the current, correct answer. If your authoritative nameserver shows your changes but public DNS servers don't, you're waiting for propagation and TTL expiration. If even your authoritative nameserver doesn't show changes you made, the changes haven't taken effect yet or were configured incorrectly.
Understanding TTL in propagation:
Look at the TTL value in dig output:
example.com. 900 IN A 192.0.2.1
The 900 means this result will be cached for 900 seconds (15 minutes). If you just made a change, different DNS servers might still serve the old cached result for up to this duration. Once TTL expires, they'll query again and get the new value.
Command 4: Identify Your Nameservers
Nameserver records determine which servers authoritatively answer DNS queries for your domain. Verifying these records confirms where DNS control actually resides.
example.com. 86400 IN NS ns1.namesilo.com.
example.com. 86400 IN NS ns2.namesilo.com.
These NS records tell you which servers are authoritative for your domain. This information is crucial for troubleshooting: if you're making changes in one place but your NS records point elsewhere, your changes won't take effect.
Common nameserver issues:
If you recently transferred your domain or changed nameservers but dig still shows old nameservers, the changes haven't propagated at the TLD level yet. This can take longer than regular DNS record changes, sometimes up to 48 hours. If you see nameservers you don't recognize, your domain might have been compromised or you might be looking at the wrong domain. This warrants immediate investigation.
Checking different levels:
Query your domain registrar's nameservers versus what's actually serving your zone:
The +trace option shows the complete DNS resolution path from root servers through TLD servers to your authoritative nameservers. This reveals where in the DNS hierarchy any problems occur.
Sample +trace output (simplified):
. 518400 IN NS a.root-servers.net.
com. 172800 IN NS a.gtld-servers.net.
example.com. 172800 IN NS ns1.namesilo.com.
example.com. 3600 IN A 192.0.2.1
This shows the resolution path: root servers know about .com servers, .com servers know about your nameservers, and your nameservers know the final answer.
Command 5: Check TXT Records for Verifications and Policies
TXT records store text data used for domain verification, email policies, and service configuration. Querying these records confirms integrations are configured correctly.
Sample output showing multiple TXT records:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=abc123xyz789"
Domains often have multiple TXT records for different purposes. dig displays all of them.
Interpreting TXT record content:
TXT records contain literal text strings. Look for patterns:
- Records starting with v=spf1 are SPF records for email authentication
- Records containing google-site-verification are Google verification tokens
- Records starting with v=DMARC1 are DMARC policies
- Records containing _domainkey in the hostname are DKIM keys
Querying specific TXT records:
For DKIM, you need the selector and subdomain:
dig selector._domainkey.example.com TXT
dig _dmarc.example.com TXT
These subdomain-specific queries reveal records that won't appear when querying the root domain.
Troubleshooting TXT record issues:
If a verification fails but dig shows the correct TXT record, the issue might be:
- Propagation delay (wait longer)
- Extra characters or quotes in the record value
- Record at the wrong hostname (verification might require _verification.example.com but you put it at example.com)
- Multiple conflicting records (particularly common with SPF)
Reading dig Output: Authoritative vs Cached Answers
Understanding whether you're seeing cached data or authoritative answers helps interpret results correctly.
The flags line reveals the source:
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
- qr - Query Response (this is a response, not a query)
- rd - Recursion Desired (you asked for recursive resolution)
- ra - Recursion Available (the server supports recursion)
- aa - Authoritative Answer (this flag appears when the server is authoritative for this domain)
Cached answers have rd and ra flags but no aa flag. You're seeing a recursive resolver's cached copy.
Authoritative answers include the aa flag. You're seeing the original, authoritative data from the domain's nameservers.
When troubleshooting changes, query authoritative servers (using @ns1.example.com) to see the current truth, and query public DNS to see what's cached and being served to users.
Practical Troubleshooting Scenarios
Scenario 1: Website not loading
If this returns no A record or the wrong IP, your DNS is misconfigured. If it returns the correct IP, the problem is likely with the web server itself, not DNS.
Scenario 2: Email not being received
Verify MX records exist and point to your email provider's servers. If they're missing or point to old servers, update them. Check mail server IPs:
Scenario 3: Changes not taking effect
dig @ns1.yourregistrar.com yourdomain.com
dig @8.8.8.8 yourdomain.com
If your authoritative nameserver shows the change but public DNS doesn't, wait for TTL expiration. If even authoritative nameservers don't show the change, it wasn't saved correctly or you're making changes in the wrong place.
Scenario 4: Intermittent DNS issues
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @9.9.9.9 yourdomain.com
If different resolvers return different results, you might have:
- Multiple nameservers with inconsistent data
- DNS load balancing that responds differently based on location
Scenario 5: Domain verification failing
dig _verification.yourdomain.com TXT
Look for the verification string in the output. If it's not there or formatted incorrectly, that's your problem. If it appears correctly, propagation might not be complete or the verification service has a bug.
Advanced dig Options Worth Knowing
+noall +answer: Shows only the answer section, cleaner than +short but still includes TTL and other useful data:
dig example.com +noall +answer
ANY query type: Attempts to retrieve all record types (though many servers now limit this):
Reverse DNS lookup: Find the hostname associated with an IP address:
+trace for full resolution path: Shows every step from root servers to final answer:
Specify record type explicitly: When querying uncommon record types:
When to Use dig vs Online Tools
Use dig command-line when:
- You need to query specific DNS servers
- You're troubleshooting systematically and need repeated queries
- You want to script or automate DNS checking
- You need precise control over query parameters
Use online dig tools when:
- You can't install software on your current system
- You want to check DNS from different geographic locations
- You're helping someone who isn't technical and can't use command line
- You need a quick one-off query
Both approaches use the same underlying DNS queries and produce essentially identical results. Choose based on convenience and your specific needs.
Building Your DNS Troubleshooting Workflow
When DNS issues occur, work through queries systematically:
- Verify the record exists: Query your authoritative nameserver directly
- Check propagation: Query several public DNS servers
- Examine TTL: Note how long old values might persist in caches
- Review related records: MX records need A records for mail servers, CNAMEs point to other names that need their own records
- Compare expected vs actual: If results don't match your configuration, investigate why
Keep notes of your findings. DNS issues often involve multiple factors, and documenting what you discover helps identify patterns.
Learning More About dig
These five commands, checking A records, MX records, querying specific servers, checking nameservers, and reviewing TXT records, handle the vast majority of DNS troubleshooting domain owners encounter. As you become comfortable with these basics, dig has many more features for advanced scenarios.
The dig manual (man dig on Unix systems) documents all options. Online resources explain advanced query types and troubleshooting techniques. But start with these fundamentals, they're surprisingly powerful once you understand what you're seeing.
DNS doesn't need to be mysterious. With dig, you can observe exactly what DNS servers are saying about your domain, verify changes have taken effect, and troubleshoot issues with confidence rather than guesswork.
.png&w=2048&q=75)
