🌐 DNS Lookup

When you enter a domain name, the tool uses Python's dnspython library to perform a recursive DNS resolution. The process begins by querying the root nameservers (managed by ICANN) to identify the authoritative nameservers for the top-level domain (.com, .org, .net, etc.). It then queries those TLD nameservers to find the authoritative nameservers specifically responsible for your domain. Finally, it sends the actual record query to those authoritative nameservers, which return the requested DNS records. The tool supports querying multiple record types: A records map a domain to an IPv4 address, AAAA records map to an IPv6 address, MX records identify mail servers that handle email for the domain, CNAME records create domain aliases pointing to another domain, TXT stores arbitrary text data commonly used for SPF email authentication and domain verification, and NS records identify the nameservers authoritative for the domain. You can query a specific record type or select "All" to request every supported record type simultaneously.

The DNS hierarchy operates as a distributed database with multiple caching layers. Your ISP operates recursive resolvers that cache responses from authoritative servers, and your operating system maintains a local DNS cache as well. When you change DNS records — for example, updating an A record to point to a new server — the change must propagate through these caching layers. The Time-To-Live (TTL) value on each DNS record specifies how long resolvers should cache it before re-querying the authoritative server. During propagation, some resolvers will return the old IP address while others return the new one, which is why DNS changes can take minutes to hours to fully propagate worldwide. The tool queries authoritative nameservers directly when possible, bypassing some caching layers to get the most current data. However, even authoritative responses may reflect cached data at the registry level, so very recent changes may not appear immediately.

Common Use Cases

System administrators verify DNS propagation after changing nameservers, updating IP addresses, or migrating hosting providers, confirming that the DNS change has reached authoritative servers. DevOps engineers troubleshoot email delivery issues by checking MX records to ensure mail servers are correctly configured, and verifying SPF (TXT) records to prevent emails from being marked as spam. Web developers confirm that a domain points to the correct IP address after deploying to a new server, and verify that CDN configurations are propagating correctly across global DNS infrastructure. Security auditors review DNS configurations to identify potential vulnerabilities like missing DMARC records, overly permissive zone transfers, or DNSSEC misconfigurations. Network engineers debug connectivity issues by comparing DNS responses from multiple sources — their local resolver, public resolvers like 8.8.8.8, and the authoritative servers directly — to identify caching or propagation problems.

Security & Privacy Considerations

DNS queries from our server will be visible to the DNS servers being queried — they see our server's IP address rather than yours. For sensitive internal DNS lookups (private domains, internal infrastructure), use local tools like dig, nslookup, or drill directly on your machine. No query data is stored on our servers after the response is returned. Be aware that DNS responses are cached at multiple levels — your ISP's resolver, your browser, your operating system, and intermediate CDNs — so recently changed records may show stale data until the TTL expires. Flush your local DNS cache (sudo systemd-resolve --flush-caches on Linux, ipconfig /flushdns on Windows) to ensure you see current data. DNS queries are transmitted in plaintext by default (port 53), which means they can be intercepted and logged by network intermediaries. DNS over HTTPS (DoH) and DNS over TLS (DoT) provide encrypted alternatives for privacy-sensitive queries.

Frequently Asked Questions