Linux下DNS工作原理、命令及调试，浏览器URL请求流程与故障排查

Alright, let's break this down step by step—DNS is the backbone of how we navigate the web, and understanding its inner workings plus the Linux tools to debug it is essential for any sysadmin or developer. Let's dive in.

At its core, DNS (Domain Name System) translates human-readable domain names (like google.com) into machine-readable IP addresses (like 8.8.8.8). Here's how the process plays out on a Linux system:

1. Local Cache Check: When you try to resolve a domain, Linux first checks its local DNS cache (managed by services like systemd-resolved or nscd) to see if the IP is already stored.
2. Recursive Query to Local DNS Server: If the cache misses, your system sends a query to the DNS servers configured in /etc/resolv.conf (usually your ISP's DNS or a public one like 8.8.8.8).
3. Iterative Resolution by Local DNS: If the local DNS server doesn't have the answer, it starts an iterative lookup:
   • First, it queries a root domain server (there are 13 global root servers) to find the authoritative server for the top-level domain (TLD) like .com.
   • Then it queries the TLD server to get the authoritative server for the specific domain (e.g., google.com).
   • Finally, it queries the authoritative server to get the IP address of the domain.
4. Result Caching and Return: The local DNS server caches the result for future queries, then sends the IP back to your Linux system, which also caches it locally.

These are the commands you'll reach for daily to interact with DNS on Linux:

• nslookup: A classic tool for basic DNS queries.
  • Example: nslookup google.com (returns the IP of google.com)
  • Specify a DNS server: nslookup google.com 8.8.8.8 (uses Google's DNS instead of your default)
• dig: More powerful than nslookup, with detailed output.
  • Basic query: dig google.com
  • Trace the full resolution path: dig +trace google.com (shows every step from root to authoritative server)
  • Reverse DNS lookup: dig -x 8.8.8.8 (finds the domain associated with an IP)
• host: A simple tool for quick lookups.
  • Example: host google.com (returns IPs)
  • Reverse lookup: host 8.8.8.8
• resolvectl: For systems using systemd-resolved (most modern distros).
  • Check current DNS configuration: resolvectl status
  • Query a domain: resolvectl query google.com
  • Flush DNS cache: resolvectl flush-caches
• /etc/resolv.conf: The configuration file that tells Linux which DNS servers to use. Key fields:
  • nameserver: The IP address of a DNS server (you can have multiple)
  • search: Append these domains to short names (e.g., search mycompany.com makes server resolve to server.mycompany.com)
  • options: Settings like timeout:2 (wait 2 seconds for a response) or rotate (cycle through DNS servers)

When you need to dig deeper into DNS issues, these techniques will help:

• Trace the resolution path: Use dig +trace <domain> to see exactly where the lookup fails (e.g., if root servers don't respond, or the authoritative server is down).
• Inspect DNS traffic: Use tcpdump to capture DNS packets and analyze them:
  • Capture all DNS traffic: tcpdump port 53
  • Capture UDP DNS traffic on any interface: tcpdump -i any udp port 53
• Check DNS service status: If using systemd-resolved, run systemctl status systemd-resolved to ensure it's running. For older systems with bind, use systemctl status named.
• Test DNS server responsiveness: Use dig @<DNS-server-IP> <domain> to test if a specific DNS server is working (e.g., dig @8.8.8.8 google.com).

When you type a URL like https://www.google.com into your browser, here's the full sequence of events:

1. Browser Cache Check: The browser first checks its own cache to see if it has the IP for www.google.com.
2. System DNS Cache Check: If the browser cache misses, it queries the system's DNS cache (managed by Linux's DNS services).
3. Local DNS Server Query: If the system cache misses, the system sends a query to the DNS servers in /etc/resolv.conf.
4. DNS Resolution: As explained earlier, the local DNS server performs iterative lookups to get the IP of www.google.com.
5. TCP/TLS Handshake: The browser uses the IP to establish a TCP connection with Google's server. For HTTPS, it then performs a TLS handshake to encrypt the connection.
6. HTTP Request: The browser sends an HTTP GET request to the server, asking for the content of https://www.google.com.
7. Server Response: The server sends back an HTTP response with the HTML, CSS, and JavaScript files for the page.
8. Page Rendering: The browser parses the response, downloads any additional resources (images, fonts), and renders the page for you to see.

Let's tackle common DNS issues and how to fix them:

1. Domain fails to resolve #

• Test basic resolution: Run dig <domain> or nslookup <domain>. If you get no answer, move to the next steps.
• Check /etc/resolv.conf: Ensure the nameserver entries are valid (e.g., 8.8.8.8 or your ISP's DNS). If the file is a symlink (common with systemd-resolved), verify the target file has correct entries.
• Trace the lookup: Use dig +trace <domain> to see where it fails. For example, if root servers don't respond, your network might be blocking DNS traffic.
• Check firewall rules: Ensure your firewall (e.g., ufw, iptables) isn't blocking UDP/TCP port 53 (DNS uses UDP for most queries, TCP for large responses).
• Verify DNS service status: Run systemctl status systemd-resolved to make sure the service is active and running.

2. DNS resolution is slow #

• Test different DNS servers: Use dig @8.8.8.8 <domain> and dig @<isp-dns-ip> <domain> to compare response times. The output shows Query time at the end.
• Flush DNS cache: Stale cache entries can cause delays. Run resolvectl flush-caches (systemd) or nscd -i hosts (nscd) to clear the cache.
• Analyze DNS traffic: Use tcpdump -tttt port 53 to see how long each query takes. If responses are slow, your network or DNS server might be overloaded.

3. Resolution returns wrong IP #

• Check /etc/hosts: The /etc/hosts file takes priority over DNS. Ensure there are no incorrect entries for the domain (e.g., 127.0.0.1 google.com would redirect you to localhost).
• Flush caches: Clear browser cache, system DNS cache, and local DNS server cache (if you control it).
• Test multiple DNS servers: Compare results from dig @8.8.8.8 <domain> and dig @1.1.1.1 <domain>. If results differ, your local DNS might be compromised or using outdated records.

内容的提问来源于stack exchange，提问作者Veeresh Reddy