“DNS server not responding” usually means a client did not get a usable reply from its resolver, the DNS server handling the lookup. The message does not identify a single repair. A disconnected local network, an unreachable configured resolver, blocked DNS traffic or a failing upstream query can all look similar in an application. First determine whether the device has connectivity, whether DNS queries reach the intended resolver and whether that resolver can answer the exact name.

A timeout is not the same as an explicit DNS reply such as NXDOMAIN or SERVFAIL. NXDOMAIN reports that a name does not exist; SERVFAIL reports that a server could not complete a query. A timeout means the client did not receive the needed response in time. Record the actual result from a DNS tool when possible before changing settings.

Confirm Local Connectivity

Check whether the device is connected to the intended Wi-Fi or wired network and has a usable local address, gateway and route. On Windows, ipconfig /all displays address, gateway and DNS settings for each adapter. Look at the active connection rather than a disconnected adapter. If every application is offline, start with the network link rather than DNS.

Try a known service or a direct, authorized IP reachability check to distinguish a general connectivity outage from a name lookup failure. A failed ping alone is not conclusive because some destinations ignore ICMP, the protocol ping commonly uses. Compare another device on the same network and, if practical, the same device on a different network. These comparisons help separate a device problem from a shared network problem.

If only one device fails, examine its network settings, VPN, security software and configured DNS address. If every device behind one router fails, look at the router's upstream connection or DNS forwarding. If a captive portal is present, complete the network's normal sign-in before concluding that the public resolver is unreachable.

Write down the DNS server addresses the device actually received or was configured to use. A router may advertise itself as the resolver and forward queries elsewhere. A browser with Secure DNS or a VPN may use a separate path. Testing an arbitrary public resolver does not establish that the configured resolver works.

Query the Configured DNS Server

Use a DNS query tool to ask the configured resolver for a known public name and the exact failing name, keeping the record type the same for comparisons. Note whether each query receives an answer, an explicit DNS error or no response. If the known name also times out, investigate the route to that resolver, its service state and network policy before inspecting the affected domain's DNS records.

On Windows, a command such as nslookup -type=A example.com. DNS_SERVER_IP requests IPv4 address records from a specific server. Replace DNS_SERVER_IP with the configured resolver's actual IP address, and replace example.com. with the name you want to test. Use the complete hostname, without a web address's scheme or path. This query selects a server for the test without changing the device's DNS settings.

If the resolver responds to known names but one domain fails repeatedly, investigate that domain separately. Its delegation, which identifies its authoritative nameservers, or its authoritative DNS service may be faulty. DNSSEC validation can also prevent a resolver from returning data that fails its DNSSEC checks. An explicit SERVFAIL or NXDOMAIN response should be investigated as that response, rather than described as a server timeout.

Compare UDP and TCP Queries

Traditional DNS commonly uses UDP port 53, and TCP port 53 is also part of normal operation. A network can pass one transport and block or mishandle the other. Compare queries for the same name and record type to the same resolver, using your tool's transport options.

With Windows nslookup, nslookup -vc -type=A example.com. DNS_SERVER_IP forces a TCP query. Substitute the same hostname and resolver address used in the previous test. A successful TCP result alongside failed UDP queries narrows the investigation to UDP handling, filtering or the resolver's behavior. Check the tool's output when interpreting a normal query, since some DNS tools automatically retry a truncated UDP response over TCP.

If small UDP replies work but larger lookups fail, check whether large UDP packets are being dropped and whether TCP is available for retries. A server can mark a UDP reply as truncated when the full answer will not fit, prompting a TCP retry. Blocking TCP can therefore break some lookups while others continue to work. These patterns suggest a transport problem, but they do not identify the failing component.

If both transports fail, check the DNS server address, route, firewall and whether the network intentionally restricts external DNS. The network or resolver operator can confirm filtering and service availability. A failure to reach the resolver is not repaired by editing a website's A record.

Compare Results with Another Resolver

When allowed by the network policy, query a second trusted recursive resolver directly for the same name and type. Do not immediately replace the device-wide setting. If the alternate answers while the configured resolver repeatedly times out, focus on the original resolver or the path to it. If both fail for several known public names, examine the network they share, while allowing for separate service failures.

Different successful answers do not necessarily mean a resolver is broken. Cached data and responses tailored to a client's location can produce differences. A private name can also be available through an organization's resolver while being absent from public DNS. Keep public-name tests separate from checks of required internal names.

Public resolvers differ in logging, filtering and encrypted DNS support. A workplace resolver may be required for internal hostnames, and replacing it with a public service can break access. Record the candidate resolver address and the result of the direct query. Evaluate privacy, local-name needs and policy before making a persistent change.

Apply the Repair and Retest

If evidence supports changing a resolver setting, note the original automatic or manual addresses and whether the change is on the device, router or VPN. Apply only one change at a time. Retest the known public name, the original failing name and any essential internal names. Restore the original setting if the new resolver cannot serve required private domains or causes other failures.

After the direct DNS query succeeds, retry the affected application. A browser can cache a previous answer or use its own Secure DNS provider, so a successful page load alone does not prove that the configured resolver answered. Conversely, a successful lookup does not guarantee that the destination website or service is available. Changing DNS also does not increase your internet plan's bandwidth or assign a new public IP address.

If the original resolver is managed by an organization or ISP, report the tested server address, network, time, query name and transport results to its operator. Remove private hostnames from public reports. If the failure affects one domain across otherwise working resolvers, send the relevant results to that domain's operator. This gives the responsible operator specific evidence for checking the service or configuration that failed.