Network Troubleshooting for Beginners: Part 2 — DNS

It happens: the computer has an address, the router responds, ping 8.8.8.8 works, but websites in the browser do not open. Most often the cause is DNS — the system that translates domain names into IP addresses. If a name cannot be converted to an address, the browser doesn’t know where to connect, even with a working connection.

How DNS records are structured and what types they are is covered in detail in the article DNS setup for email and website: Part 1 — What DNS is and the main records (A, MX). Here — only diagnostics.

Which DNS server the system uses

Linux with systemd-resolved (Ubuntu, Debian and others):

resolvectl status

The output shows DNS Servers for each interface. On other systems the servers are listed in /etc/resolv.conf:

cat /etc/resolv.conf

Windows:

ipconfig /all

The DNS Servers line shows which server the computer queries. Usually this is the router or the provider’s server.

Checking via the system mechanism

Linux with systemd-resolved:

resolvectl query google.com

This command goes the same way as ordinary programs, so it shows what the browser and applications see.

Windows and macOS:

nslookup google.com

Example of a successful nslookup response:

Server:  192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name:    google.com
Address: 142.250.184.110

• Server — the DNS server that answered;
• Name / Address — the requested name and the found address;
• Non-authoritative answer — the answer was not from the server authoritative for the domain, but from an intermediate server’s cache. For diagnostics this is fine.

An error looks like this:

** server can't find example.invalid: NXDOMAIN

NXDOMAIN means that the name does not exist. If this is returned for an existing name, the server is broken or the response is spoofed.

dig: detailed response

dig shows the query and response in full. On Linux it is included in the dnsutils package (Debian, Ubuntu) or bind-utils (RHEL and derivatives).

dig google.com

Key parts of the output:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     242     IN  A   142.250.184.110

;; SERVER: 192.168.1.1#53(192.168.1.1)

• status — NOERROR on success, NXDOMAIN — name does not exist, SERVFAIL — the server could not obtain an answer;
• ANSWER SECTION — found records; the number after the name is the time-to-live (TTL) of the record in seconds;
• SERVER — the server that answered.

Short output with just addresses:

dig +short google.com

Main technique: ask another server

If a name does not resolve, ask the same question to a public DNS server:

dig @8.8.8.8 google.com
nslookup google.com 8.8.8.8

• if there is an answer via 8.8.8.8 but not via your server — the problem is with the router’s or provider’s DNS. The solution is to change DNS servers in the network or router settings;
• no response from any server — DNS requests are likely being blocked on the path (port 53 UDP and TCP) or there is a connectivity problem;
• different servers return different addresses — possible response spoofing or a change in the record that has not yet propagated due to TTL.

Summary

• resolvectl status or ipconfig /all — which DNS server is used;
• resolvectl query and nslookup — check via the same path as applications;
• dig — detailed response and query to a specific server via @.

If the name resolves to the correct address, the host responds to ping, but the site still does not open, the next step is to check whether the required service is running on the server. The next part covers that.

Resources

• resolvectl (man7.org)
• dig (man7.org)
• nslookup (Microsoft Learn)
• Google Public DNS