Home
Laptops & Desktops
DNS Troubleshooting Guide

DNS Troubleshooting Guide

Kerry Cordero
Laptops & DesktopsServers
22 min read

 

Core Concepts of DNS

Before diving into troubleshooting, a quick review of key concepts is helpful:

  • DNS Resolver: The component on an endpoint (like your computer) that initiates DNS queries.
  • Stub Resolver: A simple resolver that relies on a recursive resolver.
  • Recursive Resolver: A server that handles DNS queries on behalf of a stub resolver, traversing the DNS hierarchy to find the answer.
  • Authoritative Nameserver: A server that holds the definitive DNS records for a specific domain.
  • DNS Hierarchy: The tree-like structure of the DNS namespace, starting from the root (“.”) and branching down to top-level domains (.com, .org), second-level domains (google.com), and subdomains (mail.google.com).
  • DNS Records: Various types of records stored in DNS, such as:
    • A (Address) Record: Maps a domain name to an IPv4 address.
    • AAAA (IPv6 Address) Record: Maps a domain name to an IPv6 address.
    • CNAME (Canonical Name) Record: Creates an alias from one domain name to another.
    • MX (Mail Exchanger) Record: Specifies mail servers for a domain.
    • NS (Name Server) Record: Specifies the authoritative nameservers for a domain.
    • SOA (Start of Authority) Record: Contains administrative information about a zone.
    • PTR (Pointer) Record: Used for reverse DNS lookups, mapping an IP address to a domain name.
  • DNS Caching: Resolvers and operating systems store successful DNS lookups to speed up future requests and reduce the load on DNS servers. This can sometimes lead to troubleshooting challenges if the cached information is outdated.
  • DNS Forwarding: A DNS server can be configured to forward queries it cannot resolve locally to another DNS server.

Troubleshooting Methodology

A systematic approach is key to efficient DNS troubleshooting:

  1. Identify the Scope: Is the issue affecting a single user, multiple users, a specific application, or the entire network?
  2. Gather Information: What is the exact error message? When did the issue start? What has changed recently? What domain name(s) are involved?
  3. Test from Different Points: Try resolving the domain name from the affected endpoint, other endpoints, and potentially from the DNS server itself.
  4. Check Basic Connectivity: Ensure the endpoint can reach the configured DNS server (e.g., using ping).
  5. Verify DNS Configuration: Double-check the DNS server settings on the endpoint and the server.
  6. Inspect DNS Server Logs: Look for errors or clues on the DNS server.
  7. Use DNS Troubleshooting Tools: Employ command-line tools and online resources to query DNS servers directly.
  8. Check Firewalls: Ensure firewalls are not blocking DNS traffic (typically UDP/TCP port 53).
  9. Consider Caching: Clear DNS caches on the endpoint and potentially on intermediate DNS servers.
  10. Examine Server-Specific Issues: If the issue is related to a specific server application (like IIS) or load balancer (like F5), investigate their configurations and logs.
  11. Escalate: If you’ve exhausted your troubleshooting steps, involve relevant teams (network, server, security).

Section 1: Network-Level DNS Troubleshooting

Network issues can prevent DNS queries from reaching the server or responses from returning to the client.

Typical Issues:

  • Firewall blocking DNS traffic.
  • Incorrect network configuration on the endpoint or DNS server.
  • Routing problems preventing communication with the DNS server.
  • DNS server is down or unreachable.
  • Network congestion or packet loss affecting DNS queries.

Troubleshooting Steps:

  1. Verify DNS Server Reachability:
    • Why: Ensures the endpoint can communicate with the configured DNS server.
    • How: Open a command prompt or terminal on the affected endpoint and run: 
      ping <DNS_Server_IP_Address>
      • Details: Replace <DNS_Server_IP_Address> with the IP address of the DNS server configured on the endpoint.
      • Expected Output: Successful replies from the DNS server.
      • Typical Errors/Output: “Request timed out,” “Destination host unreachable.”
      • Interpretation: If ping fails, there’s a network connectivity problem between the endpoint and the DNS server that needs to be addressed first (e.g., check network cables, switch ports, router configurations, and firewalls).
  2. Check Firewall Rules:
    • Why: Firewalls, both on the endpoint and in the network path, can block DNS traffic (UDP and TCP port 53).
    • How:
      • Endpoint Firewall: Check the Windows Firewall (or other endpoint security software) settings to ensure outbound UDP/TCP port 53 traffic to the DNS server is allowed.
      • Network Firewalls: Consult with network administrators to verify that no firewalls between the endpoint and the DNS server are blocking UDP/TCP port 53.
    • Details: DNS primarily uses UDP port 53 for queries and responses, but falls back to TCP port 53 for larger responses or zone transfers.
    • Typical Errors/Output: DNS resolution attempts will simply time out or fail with generic network errors.
  3. Verify IP Configuration and DNS Server Settings on the Endpoint:
    • Why: The endpoint must have a valid IP address, subnet mask, default gateway, and crucially, the correct IP address(es) of the DNS server(s).
    • How:
      • Windows: Open a command prompt and run: 
        ipconfig /all
      • Linux/macOS: Open a terminal and run: 
        ifconfig  # or ip addr show
cat /etc/resolv.conf
    • Details: Look for the “DNS Servers” entry in the output. Ensure the IP addresses listed are the intended DNS servers. Also, verify the IP address, subnet mask, and default gateway are correct for the network.
    • Typical Errors/Output: Missing or incorrect DNS server IP addresses, incorrect IP addressing.
    • Interpretation: If the DNS server IP is wrong, the endpoint will be sending DNS queries to the wrong place. Correct the network adapter settings (either manually or via DHCP).
  4. Test DNS Resolution Using nslookup or dig:
    • Why: These tools allow you to query DNS servers directly and see the resolution process. This helps differentiate between a client-side resolver issue and a problem with the DNS server itself.
    • How:
      • Windows: Open a command prompt and run: 
        nslookup <domain_name> <optional_DNS_server_IP>

        *Example:* nslookup www.google.com 8.8.8.8 (queries Google’s public DNS server)

      • Linux/macOS: Open a terminal and run: 
        dig <domain_name> @<optional_DNS_server_IP>

        *Example:* dig www.google.com @8.8.8.8

    • Details:
      • Using the optional DNS server IP allows you to bypass the endpoint’s configured DNS servers and test a specific server directly.
      • Look for the “Server” and “Address” lines in the nslookup output to see which DNS server responded.
      • In dig output, look for the ANSWER SECTION to see the resolved IP address.
    • Typical Errors/Output:
      • nslookup: “DNS request timed out,” “Server failed,” “Non-existent domain.”
      • dig: ;;<>> DiG x.x.x <<>> domain_name, ;; connection timed out; no servers could be reached.
    • Interpretation:
      • If nslookup or dig fails when querying the configured DNS server, but succeeds when querying a different, known-good DNS server (like 8.8.8.8), the issue likely lies with your configured DNS server or the network path to it.
      • If it fails even when querying a known-good external DNS server, there’s a broader network connectivity or firewall issue.
      • “Non-existent domain” or “NXDOMAIN” indicates the DNS server could not find a record for the requested domain name.
  5. Check for DNS Server Issues (from a Network Perspective):
    • Why: The DNS server itself might be down, overloaded, or experiencing network problems.
    • How:
      • Attempt to ping the DNS server from other machines on the network.
      • If you have access to the DNS server, check its network interface status and resource utilization (CPU, memory).
    • Details: If multiple clients are experiencing DNS issues, the problem is more likely with the DNS server or the network infrastructure serving it.
  6. Analyze Network Traffic (Advanced):
    • Why: Using a packet analyzer can show if DNS queries are leaving the endpoint, reaching the DNS server, and if responses are returning.
    • How: Use tools like Wireshark on the endpoint or a machine in the network path. Filter for UDP or TCP traffic on port 53.
    • Details: Look for DNS request packets leaving the client and DNS response packets returning from the server. Check for dropped packets, ICMP errors (like “Destination Unreachable”), or malformed packets.

Section 2: Server-Side DNS Troubleshooting (Including IIS)

Issues on the server itself can prevent applications from resolving domain names or serving content correctly based on hostnames. This is particularly relevant for web servers like IIS.

Typical Issues:

  • Incorrect DNS server configuration on the server.
  • DNS client service issues on the server.
  • Hosts file entries overriding DNS resolution.
  • Application-specific DNS resolution problems (e.g., an application trying to connect to a database by hostname).
  • IIS binding issues related to hostnames.
  • DNS caching issues on the server.

Troubleshooting Steps:

  1. Verify DNS Server Configuration on the Server:
    • Why: Just like an endpoint, the server needs to be configured to use the correct, reachable DNS servers.
    • How:
      • Windows Server: Open Network Connections, right-click the network adapter, select “Properties,” then “Internet Protocol Version 4 (TCP/IPv4)” or “Version 6 (TCP/IPv6),” click “Properties,” and check the “Preferred DNS server” and “Alternate DNS server” entries.
    • Details: Ensure these IP addresses point to your internal DNS servers or other reliable DNS servers.
    • Typical Errors/Output: Applications failing to connect to external resources by hostname, errors in server logs related to name resolution.
  2. Test DNS Resolution from the Server:
    • Why: Confirm that the server itself can resolve domain names.
    • How: Open a command prompt or PowerShell on the server and use nslookup or dig as described in Section 1, Step 4. Test resolving both internal and external domain names.
    • Details: Pay attention to which DNS server nslookup or dig is using for resolution.
    • Typical Errors/Output: Similar to endpoint nslookup/dig errors (timeout, server failed, NXDOMAIN).
    • Interpretation: If the server cannot resolve names, investigate its DNS client configuration and network connectivity to the configured DNS servers.
  3. Check the Hosts File:
    • Why: The hosts file (C:\Windows\System32\drivers\etc\hosts on Windows) provides static mappings of IP addresses to hostnames that override DNS resolution. An incorrect or outdated entry here can cause a server to connect to the wrong IP address.
    • How: Open the hosts file in a text editor (like Notepad, run as administrator to save changes).
    • Details: Look for entries related to the domain names or hostnames that are causing issues. Lines starting with `#` are comments and are ignored.
    • Typical Errors/Output: Connections going to an unexpected IP address.
    • Interpretation: If you find an incorrect entry, comment it out by adding a `#` at the beginning of the line or delete the line. Save the file.
  4. Restart the DNS Client Service:
    • Why: The DNS Client service on Windows caches DNS lookups. If the cache contains outdated or incorrect information, clearing and restarting the service can resolve the issue.
    • How: Open a command prompt as administrator and run: 
      ipconfig /flushdns
net stop dnscache
net start dnscache
    • Details: ipconfig /flushdns clears the local DNS resolver cache. Stopping and starting the service ensures the cache is completely reset.
    • Typical Errors/Output: Applications connecting to outdated IP addresses.
  5. Examine Server Application Logs:
    • Why: Applications often log errors related to name resolution failures.
    • How: Check the application event logs (Windows Event Viewer) or specific application log files for error messages containing hostnames or IP addresses that failed to resolve.
    • Details: The specific location and format of logs depend on the application.
    • Typical Errors/Output: “Could not resolve hostname,” “Connection refused” (sometimes a symptom of connecting to the wrong IP), specific application error codes related to network connectivity or name resolution.

Server-Side Troubleshooting: IIS Specifics

IIS (Internet Information Services) relies on DNS for several functions, including:

  • Resolving hostnames configured in site bindings.
  • Connecting to backend resources (databases, APIs) by hostname.
  • Using features like FTP or SMTP that may perform reverse DNS lookups.

Typical IIS Issues:

  • IIS site bindings configured with incorrect or unresolvable hostnames.
  • Application pools unable to resolve hostnames for backend connections.
  • Issues with SNI (Server Name Indication) if hostnames don’t resolve correctly.

Troubleshooting Steps (IIS Specific):

  1. Verify IIS Site Bindings:
    • Why: IIS uses bindings to determine which requests it should respond to. If a binding is configured with a hostname that doesn’t correctly resolve to the server’s IP address, clients won’t be able to reach the site using that hostname.
    • How: Open IIS Manager, navigate to the server, expand “Sites,” select the relevant website, and click “Bindings” in the Actions pane.
    • Details: Examine the “Host Name” column for each binding. Ensure the hostnames are spelled correctly and that they resolve to the IIS server’s IP address when tested from a client (and from the server itself using nslookup).
    • Typical Errors/Output: Clients receive “This site can’t be reached,” “DNS_PROBE_FINISHED_NXDOMAIN,” or reach the default IIS page instead of the intended site.
    • Interpretation: If the hostname in the binding is incorrect or doesn’t resolve, correct the binding or the DNS record.
  2. Test Backend Connectivity from the IIS Server:
    • Why: If your web application connects to other resources (databases, APIs, etc.) using hostnames, the IIS server needs to be able to resolve those hostnames.
    • How: From a command prompt or PowerShell on the IIS server, use nslookup or dig to resolve the hostnames of the backend resources. Then, use tools like ping or Test-NetConnection (PowerShell) to test connectivity to the resolved IP address and relevant port.
    • Details: For databases, this might involve testing connectivity to the SQL Server port (default 1433). For APIs, it would be the HTTP/HTTPS port (80/443) or a custom port.
    • Typical Errors/Output: Application errors in the browser or IIS logs indicating failed connections to backend resources (e.g., “A network-related or instance-specific error occurred while establishing a connection to SQL Server”).
    • Interpretation: If the IIS server cannot resolve the backend hostname or connect to the resulting IP/port, troubleshoot DNS resolution and network connectivity from the IIS server to the backend resource.
  3. Check Application Pool Identity Permissions:
    • Why: The identity under which an IIS application pool runs needs appropriate network permissions, which can sometimes indirectly affect its ability to perform DNS lookups, especially in complex environments with strict security.
    • How: In IIS Manager, go to “Application Pools,” select the relevant pool, right-click and choose “Advanced Settings.” Check the “Identity.”
    • Details: Ensure the identity (e.g., ApplicationPoolIdentity, NetworkService, or a custom account) has the necessary permissions on the network. While less common for basic DNS lookups, it’s worth considering in restricted environments.

Section 3: F5 Load Balancing and Wide IPs/DNS Troubleshooting

F5 BIG-IP devices are often used for load balancing and can play a significant role in DNS resolution, particularly with their Global Server Load Balancing (GSLB) feature, which uses Wide IPs. Troubleshooting DNS with F5 involves understanding how the F5 handles DNS requests and directs traffic.

Core F5 DNS Concepts:

  • Wide IP: An F5 GSLB object that represents a collection of virtual servers (pools) across different locations. When a client queries a Wide IP’s domain name, the F5’s GSLB logic determines which virtual server (and thus which physical server) should receive the request based on configured load balancing methods.
  • GSLB Listener: A virtual server on the F5 specifically configured to listen for DNS requests on UDP/TCP port 53. These listeners receive the DNS queries for Wide IPs.
  • Pools and Virtual Servers: Represent the actual applications or services being load balanced. Wide IPs reference these pools.
  • Monitors: Health checks configured on pools and pool members to determine their availability. GSLB uses monitor status to decide which pool members are eligible to receive traffic for a Wide IP.

Typical Issues:

  • Wide IP not resolving to the expected IP address.
  • GSLB listener not receiving DNS requests.
  • Incorrect GSLB load balancing method causing traffic to go to the wrong location.
  • Monitors failing, causing pool members to be marked down and excluded from GSLB responses.
  • DNS caching issues on clients or intermediate DNS servers hiding updated GSLB responses.
  • Network issues preventing DNS requests from reaching the GSLB listener.

Troubleshooting Steps:

  1. Verify GSLB Listener Status and Configuration:
    • Why: The GSLB listener is the entry point for DNS queries handled by the F5. If it’s down or misconfigured, the F5 won’t respond to DNS requests for Wide IPs.
    • How: Log in to the F5 BIG-IP web interface (GUI) or command line (tmsh).
      • GUI: Navigate to DNS > Delivery > Listeners. Check the status of the GSLB listener (should be green/available). Click on the listener to verify its IP address and service port (should be 53).
      • tmsh: 
        show ltm virtual <GSLB_Listener_Name>
    • Details: Ensure the listener is enabled and listening on the correct IP address and port 53.
    • Typical Errors/Output: Listener showing red/unavailable status, DNS queries to the Wide IP timing out.
  2. Check Wide IP Configuration:
    • Why: The Wide IP defines the domain name the F5 is responsible for and which pools are associated with it.
    • How:
      • GUI: Navigate to DNS > GSLB > Wide IPs > Wide IP List. Select the Wide IP experiencing issues.
      • tmsh: 
        list gtm wideip <Wide_IP_Name>
    • Details: Verify the “Wide IP Name” is correct. Check the “Pools” list to ensure the correct pools are associated with the Wide IP. Examine the “Load Balancing Method” to understand how the F5 is choosing a pool/virtual server.
    • Typical Errors/Output: Wide IP not resolving, resolving to an unexpected IP address, traffic going to the wrong data center.
  3. Verify Pool and Pool Member Status:
    • Why: GSLB relies on the health status of pools and their members (virtual servers) to determine which IP addresses to return in DNS responses. If pool members are marked down, they won’t be included in the response.
    • How:
      • GUI: Navigate to Local Traffic > Pools > Pool List. Select the pool associated with the Wide IP. Check the status of the pool and its members.
      • tmsh: 
        show ltm pool <Pool_Name>
    • Details: Look for the “Availability” and “State” of the pool and its members. Red/offline status indicates a problem.
    • Typical Errors/Output: Wide IP resolving to only a subset of expected IP addresses, traffic being directed away from a data center that should be active.
    • Interpretation: If pool members are down, investigate the monitors configured for that pool.
  4. Check GSLB Monitor Status and Configuration:
    • Why: Monitors actively check the health of pool members. If a monitor is misconfigured or failing, it can incorrectly mark a healthy server as down.
    • How:
      • GUI: Navigate to Local Traffic > Monitors > Monitor List. Select the monitor(s) associated with the pools used by the Wide IP.
      • tmsh: 
        list ltm monitor <Monitor_Type> <Monitor_Name>

        (Replace <Monitor_Type> with http, https, gateway_icmp, etc.)

    • Details: Examine the monitor configuration (destination, interval, timeout, send/receive strings for HTTP/HTTPS monitors). Check the monitor’s status.
    • Typical Errors/Output: Pool members flapping between up and down, pool members consistently marked down despite the application being available.
    • Interpretation: Ensure the monitor is configured correctly to test the actual service health. Test the monitor destination (IP and port) from the F5 command line using tools like ping or curl (if it’s an HTTP/HTTPS monitor) to rule out network issues between the F5 and the pool member.
  5. Use dig or nslookup to Query the F5’s GSLB Listener Directly:
    • Why: This bypasses any intermediate DNS servers and client-side caching, allowing you to see how the F5 is responding to DNS queries for the Wide IP.
    • How: From a machine that can reach the F5’s GSLB listener IP, open a command prompt or terminal and run: 
      dig <Wide_IP_Name> @<F5_GSLB_Listener_IP>  # Linux/macOS
nslookup <Wide_IP_Name> <F5_GSLB_Listener_IP> # Windows
    • Details: Observe the IP address(es) returned in the answer section. Compare this to the expected IP addresses based on your GSLB configuration and pool member status.
    • Typical Errors/Output: No answer section, unexpected IP addresses returned, timeouts.
    • Interpretation: If the F5 returns the correct IP addresses when queried directly, the issue is likely with caching on intermediate DNS servers or the client, or a different DNS server is being queried. If the F5 returns incorrect or no results, the issue is within the F5’s GSLB configuration or the health of the underlying pools/members.
  6. Check DNS Cache on Intermediate DNS Servers:
    • Why: If there are DNS servers between the client and the F5 GSLB listener, they may have cached an old DNS response for the Wide IP.
    • How: If you manage the intermediate DNS servers, check their cache for the Wide IP’s record. Some DNS server software allows manual cache flushing for specific records or the entire cache.
    • Details: The duration for which DNS records are cached is determined by the Time To Live (TTL) value in the DNS record. F5 Wide IPs have configurable TTLs.
    • Typical Errors/Output: Clients resolving the Wide IP to an IP address that is no longer active or correct.
    • Interpretation: Consider lowering the TTL on the Wide IP if frequent changes are expected (though very low TTLs can increase DNS traffic). Clearing the cache on intermediate servers can temporarily resolve the issue but the underlying cause (e.g., a long TTL) should be addressed if necessary.
  7. Review F5 GSLB Logs:
    • Why: F5 logs can provide insights into why the GSLB made a specific load balancing decision or if there were errors processing DNS requests.
    • How: Access the F5 logs via the GUI (System > Logs > GSLB > Bind Requests or System > Logs > Local Traffic > Audit) or the command line (tail /var/log/gtm).
    • Details: Look for entries related to the Wide IP and the source IP of the client performing the DNS query. The logs can show which pools were considered and why a particular decision was made.
  8. Network Connectivity to GSLB Listener:
    • Why: Ensure that the DNS requests from clients or intermediate DNS servers can actually reach the F5’s GSLB listener IP address.
    • How: Use ping or a port scanner (like nmap) from the client’s network or the intermediate DNS server to the F5 GSLB listener IP on port 53 (UDP and TCP).
    • Details: Confirm that firewalls or routing devices in the path are not blocking this traffic.

Section 4: Endpoint DNS Troubleshooting (Windows 11)

Troubleshooting DNS on an end-user’s Windows 11 machine is a common task. Issues here prevent the user from accessing websites, network resources, and cloud services by name.

Typical Issues:

  • Incorrectly configured DNS server addresses.
  • DNS client service is stopped or malfunctioning.
  • Outdated or corrupt DNS client cache.
  • Issues with DHCP providing incorrect DNS information.
  • Firewall blocking DNS traffic on the endpoint.
  • Problems with the network adapter.
  • VPN or security software interfering with DNS.
  • Hosts file entries.

Troubleshooting Steps:

  1. Check Network Adapter Status and Configuration:
    • Why: The network adapter must be enabled and configured with the correct IP settings, including DNS server addresses.
    • How:
      • Right-click the network icon in the system tray.
      • Select “Network and Internet settings.”
      • Click on the active network connection (Wi-Fi or Ethernet).
      • Scroll down and click “View hardware and connection properties.”
    • Details: Verify that the adapter is enabled, has a valid IPv4 and/or IPv6 address, and the “DNS servers listed” are the expected IP addresses. If using DHCP, check if a DHCP server IP is listed.
    • Typical Errors/Output: “No network access,” “Unidentified network,” missing DNS server entries.
  2. Verify and Test Configured DNS Servers:
    • Why: Ensure the DNS servers configured on the endpoint are reachable and functional.
    • How:
      • Open a command prompt.
      • Run ipconfig /all to see the configured DNS servers.
      • Use ping <DNS_Server_IP_Address> for each listed DNS server to check reachability (as in Section 1, Step 1).
      • Use nslookup <domain_name> <DNS_Server_IP_Address> to test if each DNS server can resolve names (as in Section 1, Step 4).
    • Details: Test resolving both internal and external domain names.
    • Typical Errors/Output: Ping failures, nslookup timeouts or “Server failed.”
    • Interpretation: If a configured DNS server is unreachable or cannot resolve names, you’ll need to either correct the network issue preventing reachability or update the endpoint’s DNS server settings.
  3. Flush the DNS Client Cache:
    • Why: The Windows DNS client caches successful lookups. If a DNS record has changed recently and the cache hasn’t expired, the endpoint might still be using the old, incorrect IP address.
    • How: Open a command prompt as administrator and run: 
      ipconfig /flushdns
    • Details: You should see a confirmation message: “Windows IP Configuration Successfully flushed the DNS Resolver Cache.”
    • Typical Errors/Output: Connecting to an outdated IP address for a website or resource.
  4. Restart the DNS Client Service:
    • Why: Sometimes the DNS Client service itself can encounter issues. Restarting it can resolve transient problems.
    • How: Open a command prompt as administrator and run: 
      net stop dnscache
net start dnscache
    • Details: Confirm that the service stops and starts successfully.
    • Typical Errors/Output: DNS resolution randomly failing or being inconsistent.
  5. Check the Hosts File:
    • Why: Similar to servers, the hosts file on a Windows 11 endpoint (C:\Windows\System32\drivers\etc\hosts) can override DNS resolution. Malware or misconfigurations can add malicious or incorrect entries here.
    • How: Open Notepad as administrator and open the file C:\Windows\System32\drivers\etc\hosts.
    • Details: Examine the file for any suspicious or incorrect entries mapping domain names to IP addresses.
    • Typical Errors/Output: A specific website or domain name resolving to the wrong IP address, potentially leading to fake websites or blocked access.
  6. Temporarily Disable Firewall/Security Software:
    • Why: Endpoint firewalls or security software can sometimes incorrectly block DNS traffic.
    • How: Temporarily disable the Windows Firewall and any third-party security software.
    • Details: Caution: Only do this temporarily for testing and in a controlled environment. Remember to re-enable them afterward.
    • Typical Errors/Output: All or specific DNS lookups failing when the firewall is enabled.
  7. Renew DHCP Lease (if using DHCP):
    • Why: If the endpoint is configured to obtain network settings via DHCP, renewing the lease ensures it receives the latest IP address, subnet mask, default gateway, and DNS server information from the DHCP server.
    • How: Open a command prompt and run: 
      ipconfig /release
ipconfig /renew
    • Details: ipconfig /release releases the current IP address, and ipconfig /renew requests a new one from the DHCP server.
    • Typical Errors/Output: Endpoint having an incorrect or expired IP address, unable to reach the network.
  8. Test with a Different DNS Server:
    • Why: To determine if the issue is with your primary configured DNS servers or something else.
    • How: Temporarily change the DNS server settings on your network adapter to a public, reliable DNS server like Google DNS (8.8.8.8 and 8.8.4.4) or Cloudflare DNS (1.1.1.1 and 1.0.0.1).
    • Details: If changing to a public DNS server resolves the issue, the problem lies with your original configured DNS servers or the network path to them. Remember to revert the settings afterward.
  9. Check VPN or Proxy Settings:
    • Why: VPN clients or proxy settings can redirect network traffic, including DNS queries, which can lead to resolution issues if misconfigured or if the VPN/proxy’s DNS servers are having problems.
    • How: Check the settings of your VPN client or any configured proxy settings in your browser or system network settings. Temporarily disconnect the VPN or disable the proxy for testing.
    • Details: Some VPNs have their own DNS servers or force DNS traffic through the VPN tunnel.
    • Typical Errors/Output: Inability to reach internal network resources when connected to VPN, unexpected website behavior.
  10. Use the Network Troubleshooter:
    • Why: Windows has built-in troubleshooters that can automatically detect and fix common network problems, including DNS issues.
    • How: Go to Settings > Network & internet > Advanced network settings > Network troubleshooter. Select the network adapter you want to troubleshoot.
    • Details: The troubleshooter will attempt to identify and fix issues like incorrect IP configuration or DNS server problems.

Typical DNS-Related Errors and HTTP Status Codes

While DNS itself doesn’t use HTTP status codes, problems with DNS resolution often manifest as errors in web browsers or applications that rely on successfully resolving a domain name to an IP address before making an HTTP request.

Common DNS-Related Errors Seen by Users:

  • DNS_PROBE_FINISHED_NXDOMAIN: This is a very common browser error indicating that the DNS lookup for the domain name failed because the domain does not exist (NXDOMAIN – Non-Existent Domain).
  • DNS_PROBE_FINISHED_NO_INTERNET: Can sometimes be related to DNS issues, suggesting the browser couldn’t reach the internet, which might be due to an inability to resolve the domain name of the site it’s trying to reach or core internet services.
  • DNS_UNRESOLVED_HOSTNAME: The browser or application was unable to translate the hostname into an IP address.
  • Server Not Found: A generic error indicating that the browser could not connect to a server, often a result of a DNS resolution failure.
  • This site can’t be reached: Another common browser error encompassing various connectivity problems, including DNS failures.
  • Request timed out: Can occur during DNS lookups if the DNS server is unreachable or slow to respond.

HTTP Status Codes (Indirectly Related to DNS Issues):

If DNS resolution succeeds but points to the wrong server or an unavailable server, you might see HTTP errors after the browser attempts to connect to the resolved IP address.

  • 400 Bad Request: While usually related to the request itself, a misconfigured application or load balancer due to a DNS issue could potentially contribute.
  • 404 Not Found: If DNS resolves to a server that doesn’t host the requested content, you might see a 404 from that server.
  • 500 Internal Server Error: Could occur if a server-side application fails because it cannot resolve a backend hostname after a successful initial DNS lookup for the web server.
  • 502 Bad Gateway: A load balancer or proxy received an invalid response from an upstream server. This could be indirectly related if the load balancer is trying to forward traffic to a backend server whose IP was incorrectly resolved due to a DNS issue.
  • 503 Service Unavailable: The server is currently unable to handle the request. This might happen if a service the server depends on (like a database accessed by hostname) is unreachable due to a DNS issue.
  • 504 Gateway Timeout: A load balancer or proxy did not receive a timely response from an upstream server. Similar to 502, this could be indirectly caused by difficulties reaching a backend due to DNS problems.

Command-Line Tool Output Examples:

  • nslookup: 
    Server:  UnKnown
Address:  192.168.1.1

Non-existent domain.

    *Interpretation: The DNS server (192.168.1.1) was reached, but it reported that the domain name does not exist.*

    DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.1.1

*** Can't find <domain_name>: Request timed out

    *Interpretation: The DNS server (192.168.1.1) did not respond to the DNS query within the timeout period, possibly due to network issues or the server being down.*

  • dig: 
    ;; connection timed out; no servers could be reached

    *Interpretation: The dig command could not connect to the specified DNS server(s) on port 53.*

    ;; ANSWER SECTION:
www.google.com.		299	IN	A	172.217.160.142

    *Interpretation: The DNS server successfully resolved www.google.com to the IP address 172.217.160.142 with a TTL of 299 seconds.*

    ;; AUTHORITY SECTION:
google.com.		172800	IN	SOA	ns1.google.com. dns-admin.google.com. 2023102602 900 2400 604800 86400
;; WARNING: recursion requested but not available

    *Interpretation: The DNS server (which is likely not a recursive resolver in this example) returned an NXDOMAIN response, indicating the domain wasn’t found in its authoritative data.*

 

© 2025 cordero.me • All Rights Reserved