First prove the delay is in DNS rather than the application
A page that opens slowly can be caused by DNS, TCP connection setup, TLS negotiation, server processing, packet loss, or content transfer. Measure the name lookup independently. If nslookup returns immediately but the browser remains slow, DNS is not the main delay for that test.
Apply the cache and dependency distinctions in AP Networking DNS Resolution Practice Test. The harder items include warm answers hiding an upstream failure, negative-cache timelines, stale delegation and browser resolver choices that differ from an operating-system test.
Cached and uncached lookup times tell different stories
The first lookup may require recursive work while a repeated lookup can be answered from cache. Compare both. If the first query takes seconds and the second is nearly instant, caching is working but upstream recursion or the authoritative path may be slow. If every query is slow, the client-to-resolver path or resolver itself becomes more relevant.
Compare the configured resolver with another permitted resolver
A large difference in response time can identify a slow local forwarder or recursive resolver. Keep the query name and client path as constant as possible. Do not permanently bypass enterprise DNS without considering internal names, policy, and security requirements.
Packet loss can turn a tiny DNS exchange into seconds of delay
DNS often begins with UDP. If a request or response is lost, the client waits and retries, making the lookup feel disproportionately slow. Compare network loss and latency to the resolver. Intermittent packet loss can therefore appear as inconsistent name-resolution delay.
Each forwarding layer can add another dependency
An enterprise DNS server may forward unresolved queries to another resolver. If the local server answers cached/internal names quickly but external uncached names slowly, inspect the forwarding/upstream path rather than blaming the client. Resolver logs and timing can expose where the delay begins.
Multiple address-family queries can affect perceived delay
Modern clients can query A and AAAA records and may try multiple connection paths. A slow or broken path for one address family can complicate the user's experience even when DNS itself returns both records. Keep resolution time separate from subsequent connection-selection behavior.
Short TTLs can increase repeated recursive work
A very short TTL causes cached records to expire frequently. That can be intentional, but it means more queries require upstream work. A long TTL improves cache reuse but makes changes propagate more slowly. Troubleshooting should observe the actual TTL rather than assuming the cache is defective.
Measure before and after with the same query conditions
After changing a resolver, forwarder, network path, or cache issue, repeat the same query from the same client and record the response time. Then test the real application. A faster DNS query is useful, but the user's complaint is only solved if the end-to-end task improves.