1. Measure before you change anything
From a terminal, dig example.com (or nslookup example.com on Windows) prints the query time. Run it twice: the first answer is uncached, the second comes from cache. Compare against a fast public resolver with dig @1.1.1.1 example.com. You can also verify what your zone currently serves with our DNS lookup tool.
2. The usual causes, fastest wins first
Slow or distant resolver (affects your browsing)
ISP resolvers are often overloaded or far away. Switching your device or router to 1.1.1.1, 8.8.8.8 or 9.9.9.9 typically cuts uncached lookups dramatically and is completely reversible.
Slow authoritative DNS (affects your visitors)
If your domain's name servers sit in a single datacenter, a visitor on another continent pays the round trip on every uncached lookup. Anycast DNS providers answer from dozens of locations worldwide. Check your current NS records with the DNS checker — if they belong to a basic registrar service, migrating to an anycast provider is usually the single biggest improvement.
TTLs set too low
A TTL of 60 seconds means resolvers throw the answer away every minute and ask again. Unless you are mid-migration, raise TTLs on stable records to 1–24 hours so caches actually work.
Long CNAME chains
Each CNAME hop can require a separate resolution. www → shop.platform.com → lb.platform-cdn.net → ... multiplies latency. Flatten chains where possible, or use ALIAS/ANAME records at providers that support them.
Lookups your pages didn't need
Every third-party hostname on a page (fonts, analytics, ads, widgets) costs its own DNS lookup on first visit. Trim unused third parties and add <link rel="dns-prefetch"> / <link rel="preconnect"> hints for the critical ones.
3. Verify the fix
Re-run your dig measurements after each change, from more than one network if you can. Externally, keep an eye on Time to First Byte in your analytics or a monitoring service — DNS improvements show up there first.