Resolving and Troubleshooting DNS with Dig

1. Getting Started with dig

dig (Domain Information Groper) is the professional's tool for DNS lookups. It provides detailed information that is essential for diagnostics.

Installation on Fedora

First, let's make sure dig is installed on your Fedora system. It's part of the bind-utils package. Open your terminal and run:

sudo dnf install bind-utils

You can verify it's installed by checking its version: dig -v.

Your First Lookup and Understanding the Output

Let's start with a basic query. We'll ask for the IP address of fedoraproject.org:

dig fedoraproject.org

You'll see a detailed, multi-section output that can seem intimidating at first. Let's watch a video that breaks it down clearly.

As the video showed, the two most important sections are:

• ;; QUESTION SECTION:: This confirms what you asked for. By default, dig asks for the A record (the IPv4 address).
• ;; ANSWER SECTION:: This is the answer from the DNS server. It contains the domain, the Time To Live (TTL), the record class (IN for internet), the record type (A), and the value (the IP address).

Simplifying the Output

While the detailed output is great for troubleshooting, you often just want the answer. dig has options for that.

To summarize:

• dig example.com +short: Gives you only the answer (e.g., 93.184.216.34).
• dig example.com +noall +answer: Gives you the full answer line, including the domain, TTL, and record type. This is often more useful than +short because it provides more context.

2. Querying Key DNS Record Types

A domain's DNS configuration is made up of many different types of records, each serving a specific purpose. As a developer, you need to be familiar with several of them.

Here's why these records matter in web development:

• A (Address) & AAAA (Quad-A): These map your domain to an IPv4 or IPv6 address, respectively. This is the most fundamental record, pointing users to your web server. When you deploy a site, you'll use dig to verify this record points to your new host's IP.

  dig example.com A +noall +answer
  dig example.com AAAA +noall +answer
  

• CNAME (Canonical Name): An alias for another domain. A common use is pointing the www subdomain to your main domain (e.g., www.example.com is an alias for example.com).

  dig www.fedoraproject.org +noall +answer
  

• MX (Mail Exchange): Tells mail servers where to deliver email for your domain. If your Django app's contact form emails aren't arriving, the first thing to check is if the MX records are correct for your email provider (like Google Workspace or SendGrid).

  dig google.com MX +short
  

• TXT (Text): A free-form text record used for various verification purposes. You'll use this to prove you own a domain for Google Search Console, to set up SPF (Sender Policy Framework) records to prevent email spoofing, and for some SSL certificate validation methods.

  dig fedoraproject.org TXT +noall +answer
  

• NS (Name Server): Specifies the authoritative name servers for your domain. If you're not sure where a client's DNS is managed (e.g., at the registrar like GoDaddy or a third-party like Cloudflare), querying the NS record will tell you.

  dig fedoraproject.org NS +short
  

3. DNS Troubleshooting Techniques

Now for the most important part: using dig to diagnose problems.

Problem 1: "Is the change live, or is my computer just seeing an old, cached result?"

When you change a DNS record, it can take time for it to "propagate" across the internet. Your local machine or ISP might have the old record cached. To bypass this, you can tell dig to ask a specific public DNS server directly.

The syntax is dig <domain> @<dns-server-ip>. If dig example.com shows the old IP but dig example.com @1.1.1.1 shows the new one, you've confirmed your change is live and you just need to wait for local caches to expire.

Problem 2: "Why is a domain not resolving at all?"

Sometimes, a lookup just fails. The +trace option is your ultimate diagnostic tool. It shows you the entire resolution path, step-by-step, starting from the internet's root DNS servers.

This is invaluable for spotting where in the chain a failure is occurring.

Problem 3: "What hostname does this IP address belong to?"

A reverse DNS lookup does the opposite of a normal query: it finds the hostname associated with an IP address. This is useful for checking server configurations or identifying the source of traffic in logs.

dig -x 8.8.8.8 +short

This should return dns.google..

Interpreting Error Statuses

In the HEADER section of the verbose dig output, the status field is critical.

• NOERROR: The query was successful and an answer was found (even if the answer section is empty).
• NXDOMAIN: "Non-Existent Domain". The name you queried does not exist. This is usually a typo.
• SERVFAIL: The server failed to process your request. This could be an issue with the authoritative name server for the domain or a network problem. This is when you would use +trace or query other public resolvers to investigate further.

4. Do-It-Yourself: DNS Detective Work

Time to apply your new skills. Open your terminal and perform these investigations.

Task 1: Basic Lookups

1. Find the IPv4 address for github.com. First, do a full lookup, then get just the answer section, and finally get only the IP address with +short.
2. Find the IPv6 address (the AAAA record) for google.com.

Task 2: Web Infrastructure Investigation

1. As a Django developer, you'll work with PostgreSQL. Find out who handles email for postgresql.org by querying its MX records.
2. Find the NS (Name Server) records for python.org. This tells you who manages their DNS infrastructure.

Task 3: Propagation and Troubleshooting

1. Check the A record for elementor.com using your default resolver (dig elementor.com +short).
2. Now, check it again using Cloudflare's public DNS: dig elementor.com @1.1.1.1 +short.
3. And again using Google's public DNS: dig elementor.com @8.8.8.8 +short.
4. Are the answers the same? This is exactly how you would check if a DNS change has propagated globally.

Task 4: Trace the Path

1. Run a full DNS trace for djangoproject.com to see the complete resolution path.

   dig djangoproject.com +trace
   

Task 5: Reverse Lookup

1. Cloudflare runs a public DNS resolver at the IP 1.1.1.1. Perform a reverse lookup to find its hostname.

   dig -x 1.1.1.1 +noall +answer
   

Conclusion

Excellent work. You've now unlocked one of the most powerful diagnostic tools for any system administrator or web developer. You're no longer in the dark when a domain fails to load; you have the tool to methodically find out why.

Key Takeaways:

• dig is the standard tool for querying the Domain Name System from the command line.
• The most important DNS records for a web developer are A/AAAA (IP), CNAME (alias), MX (mail), TXT (verification), and NS (authoritative server).
• Troubleshooting DNS involves three key techniques:
  1. Interpreting the status (NOERROR, NXDOMAIN, SERVFAIL).
  2. Bypassing local caches by querying public resolvers directly (e.g., dig example.com @8.8.8.8).
  3. Following the entire resolution path from the root servers down (dig example.com +trace).

You've now confirmed a server is reachable (ping), mapped the path to it (traceroute), verified the web service is running (curl), and can now troubleshoot the address book that ties it all together (dig).

In our next lesson, we will look at the local side of the connection. Once you know a remote server is up and listening, how can you tell what services are listening for connections on your own system? We'll explore the ss command to identify listening ports and active network connections.