DNS Lookup

This tool and your local nslookup command are very likely querying different resolvers. This page queries Google's public DNS-over-HTTPS resolver (dns.google) directly. Your OS-level nslookup typically queries whatever resolver your network is configured to use — your ISP, your router, or a corporate DNS server — which may have a different, possibly stale, cached copy of the same records. If the two disagree, the difference usually points to caching, not an actual DNS error.

Not directly. DNS records tell you where a domain points — its IP addresses, mail servers, and nameservers — but not who registered it. Ownership and registrant information (where publicly available) is what our WHOIS Lookup tool is for; the two tools answer different questions and are commonly used together when investigating a domain.

Propagation delay comes from TTL (Time To Live) caching at every resolver between you and the authoritative nameserver — each resolver holds onto an old answer until its TTL expires, regardless of how fast the authoritative record actually changed. You can meaningfully speed up future changes by lowering your TTL (e.g. to 300 seconds) well before you make the change, so the old, longer TTL has already expired everywhere by the time you need the new record to take effect. Lowering TTL after you've already made the change won't help the caches that already have the old value.

Yes — this is exactly what SPF, DKIM, and DMARC TXT records are for. SPF specifies which mail servers are authorized to send on behalf of your domain; DKIM lets receiving servers cryptographically verify a message wasn't altered in transit; DMARC tells receiving servers what to do (reject, quarantine, or allow) when SPF or DKIM checks fail. A domain missing all three is significantly easier to spoof convincingly in phishing campaigns.

The most common cause is a stale local or ISP-level cache on your own device still holding an old, working answer while the authoritative record has genuinely changed or expired since. Less commonly, it can indicate the domain is using split-horizon DNS (see below), where an internal, non-public record resolves inside a specific network but no public record exists — your browser may be resolving it through a VPN or corporate DNS you're connected to, which this public tool can't see.

Yes, for a specific reason: standard DNS queries are sent in plaintext over UDP port 53, meaning anyone on the network path — your ISP, a coffee shop Wi-Fi operator, a network administrator — can see every domain you look up. DoH wraps the same query inside an encrypted HTTPS connection, hiding the query content from anyone monitoring the network, though the DoH provider itself (Google, Cloudflare, etc.) still sees the query, so it shifts who can see your lookups rather than eliminating visibility entirely. Run our DNS leak test to check which resolver your own traffic is actually using right now.

Yes — this is one of the more damaging attack vectors in practice. If an attacker gains access to your domain registrar or DNS provider account, changing your NS or A records can redirect your entire domain's traffic, including email, to servers they control. This is why enabling two-factor authentication at your registrar and DNS provider, and enabling a registrar lock, matters as much as any application-level security measure — our WHOIS Lookup tool is a quick way to check a domain's current registrar and expiration status if you suspect something changed.

This DNS Lookup tool queries records for any domain you choose — it's a general-purpose diagnostic for how a domain is configured. Our DNS leak test instead checks which DNS resolvers your own device is actually sending queries through right now, which matters for privacy because a misconfigured VPN can leak your queries to your ISP's resolver even while your browsing traffic is tunneled. They're complementary: one investigates a domain, the other investigates your own exposure.