Start by identifying what timed out
A DNS query timeout means a requester did not receive a usable response before it stopped waiting. It does not, by itself, tell you whether the domain, your device, a recursive resolver, or an authoritative nameserver is at fault. It is also different from NXDOMAIN, which says a queried name does not exist, and SERVFAIL, which says a DNS server could not complete the lookup. Record the exact error rather than treating every failed lookup as a timeout.
Note the name and record type being queried, the device and network where the failure occurs, and whether it happens every time or only occasionally. Try a familiar domain as a comparison. If many unrelated names time out on one device, begin with that device’s network connection and DNS settings. If only one domain fails across multiple networks, investigate that domain’s authoritative DNS. These comparisons narrow the search without requiring changes to the domain.
Check the recursive resolver first
Most devices ask a recursive resolver to find DNS answers on their behalf. Your router, internet provider, workplace network, or a configured DNS service may supply that resolver. Use a DNS lookup tool such as dig or nslookup to see which server receives your query and whether it responds. For example, dig your-domain.example A queries the device’s configured resolver. Replace the placeholder with a domain you are permitted to test; the example name is not intended to resolve.
Compare the result with a query sent to another resolver you are authorized to use. If one resolver times out while another answers, check the first resolver’s availability, its configured address, and any firewall or VPN path between your device and it. If both answer but return different results, examine the response details rather than assuming a timeout. Caching and DNS configuration can produce differences that need a separate explanation.
A web browser alone is a limited test: it may reuse connections, cache answers, or report several connection failures in similar language. Keep the DNS lookup output so you can tell whether a response arrived, which server provided it, and what error it reported.
Find out whether authoritative nameservers respond
If recursive resolvers struggle with one domain, check the domain’s delegation. The parent zone lists the nameservers responsible for the domain; those authoritative servers should be reachable and able to answer for it. A lookup tool’s trace option can help show the path from the DNS hierarchy toward those servers. Compare the parent’s nameserver list with the nameservers configured for the domain, and check that each listed server has a reachable address.
Query each authoritative server directly for the same name and record type. A working server should return an appropriate DNS response, even when the requested record does not exist. If one server responds and another consistently times out, the problem may affect only the second server or its network path. That can create intermittent failures because different resolvers may contact different authoritative servers.
If nameserver hostnames depend on the domain they serve, verify that the parent has the necessary address information, often called glue records. Missing or incorrect glue can prevent resolvers from reaching the servers even when the DNS service itself is running.
Test the network path without overreading one result
DNS commonly uses UDP on port 53 and can use TCP on port 53 as well. A timeout can result from an offline service, an incorrect server address, routing trouble, packet filtering, or a server that is too busy to respond. If you manage the server, check that its DNS service is listening on the expected addresses and that firewall rules permit the intended clients. If you do not manage it, collect repeatable test results before asking its operator for help.
Compare UDP and TCP queries to the same server, using a lookup tool’s TCP option where available. If TCP works but UDP repeatedly times out, investigate filtering or problems carrying larger UDP responses. If neither works, check the server address and network route before changing DNS records. A failed ping is not proof that DNS is unreachable: a host may ignore ICMP echo requests while still answering DNS. Likewise, a successful ping does not prove its DNS service is healthy.
Make one change at a time and verify it
Fixes depend on where the failure occurs. A device using the wrong resolver needs a local configuration change; an unreachable authoritative server may need a service or network repair; an incorrect delegation needs an update where the domain is registered. DNSSEC validation problems can also prevent a resolver from returning an answer, but they often appear as SERVFAIL rather than a simple timeout. Keep those errors separate during diagnosis.
After a change, repeat the same queries from more than one network or resolver and test every authoritative server, not just the first one that answers. Cached answers can temporarily obscure whether a repair worked, so allow for the relevant cache lifetime when comparing results. Save the queried name and record type, server addresses, response codes, and approximate test times in your notes. That small record makes a recurring or intermittent timeout much easier to isolate.
