BrowserTools
Advertisement
Home / Networking / DNS Lookup

DNS Lookup

Query DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA) for any public domain.

Loading DNS Lookup… If nothing happens, please enable JavaScript.

Frequently asked questions

What data does this tool send to your servers?
Only the domain name you type into the search box is sent to our server. We do not log your IP address alongside your queries or store any personally identifying information. Query results are cached briefly to reduce load but are not associated with individual users.
Which DNS record types are supported?
The tool supports A, AAAA, MX, TXT, NS, CNAME, SOA, and CAA record types. These cover the vast majority of operational needs, from address resolution and mail routing to domain verification and certificate authority restrictions. PTR (reverse DNS) lookups are not currently included.
My DNS change isn't showing up — how long does propagation take?
Propagation time depends on the TTL of the old record. If the previous TTL was 3600 seconds (one hour), resolvers that cached the old record will keep serving it for up to an hour before re-querying. Setting a low TTL (300–600 seconds) before making a planned change greatly speeds up propagation. Global propagation to all resolvers worldwide can take up to 48 hours in the worst case.
What does the SOA record tell me?
The Start of Authority record identifies the primary nameserver for the zone, the responsible contact email (encoded with a dot instead of @), the zone serial number (a version counter incremented on every change), and timing parameters for secondary nameserver refresh and retry intervals. If two nameservers disagree on zone content, comparing their SOA serial numbers reveals which has the latest data.
Are there rate limits on how many lookups I can do?
Yes. To keep the service free and available for everyone, per-IP rate limits are applied on backend DNS queries. Light everyday usage is never affected. Automated bulk lookups will be throttled and may receive temporary blocks. For high-volume scripted needs, consider running your own resolver or using a commercial DNS API.
How does this compare to running 'dig' or 'nslookup' in a terminal?
The tool is functionally equivalent to 'dig @8.8.8.8 example.com ANY' for the record types it supports. It queries from our server's location, which can be useful for checking how DNS looks from a different network region. 'dig' and 'nslookup' query from your local machine and can also target specific nameservers, which is useful when testing zone changes before they propagate.
What is DNSSEC and will I see it in the results?
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records so that resolvers can verify responses haven't been tampered with in transit. When DNSSEC is enabled, you will see additional record types like RRSIG, DNSKEY, and DS in a raw dig query. This tool currently focuses on the operational record types rather than raw DNSSEC chain data, but a signed zone will show NS and SOA records with correct delegation.
Does this tool log my queries for analytics or advertising?
No. Domain queries are used only to perform the lookup and return results to you. We do not build query histories, share data with advertisers, or associate queries with user accounts. Aggregate, non-identifying usage statistics (such as total query count) may be tracked for capacity planning.
What is a CNAME record and when should I use one?
A CNAME (Canonical Name) record creates an alias from one hostname to another. For example, www.example.com can CNAME to example.com so both resolve to the same IP address. Importantly, a CNAME cannot coexist with other record types on the same hostname, which is why the zone apex (bare domain like example.com) cannot use a CNAME — you must use an A record there instead.
Can I look up DNS records for private or internal domains?
No. Queries are resolved using public DNS infrastructure and our server only queries publicly routable domains. Internal hostnames that exist only on a private corporate DNS server or a home router (like printer.local or server.corp) will not resolve. To look up internal DNS, you would need to run 'dig' or 'nslookup' from within the network where those records are hosted.

About DNS Lookup

The Domain Name System (DNS) is the phonebook of the internet, translating human-readable hostnames like example.com into the numeric IP addresses that computers actually use to route traffic. Without DNS, every user would need to memorize IP addresses for every website they visit. DNS is a hierarchical, distributed database managed by authoritative nameservers around the world, and it handles billions of queries every second. Beyond simple address lookups, DNS records carry a rich variety of information including mail server configurations, domain ownership verification tokens, security policies, and cryptographic signatures.

Sysadmins reach for DNS lookup tools when troubleshooting email delivery failures (checking MX and SPF TXT records), diagnosing website downtime (verifying A and AAAA records point to the correct server), or validating that a recent DNS change has propagated globally. Developers use it to confirm that domain verification challenges for SSL certificates or third-party services like Google Search Console are correctly published. Security teams query CAA records to restrict which certificate authorities can issue certificates for a domain, reducing the risk of mis-issuance. Even regular users can benefit from checking whether their domain registrar has correctly set up their nameservers.

This tool performs live DNS queries from our server against the public DNS infrastructure, so results reflect what the wider internet sees rather than your local resolver or ISP cache. You can query all the major record types: A (IPv4 address), AAAA (IPv6 address), MX (mail exchange), TXT (text, used for SPF, DKIM, and domain verification), NS (nameservers), CNAME (canonical name alias), SOA (start of authority, showing the primary nameserver and zone serial), and CAA (certification authority authorisation). Queries are briefly cached on our end to reduce load on authoritative nameservers and keep the service free for everyone. No personally identifying data is retained after the response is returned.

When interpreting results, pay attention to the TTL (Time to Live) value next to each record — it tells you how long resolvers will cache that record before re-querying. A very low TTL (under 300 seconds) often means the domain owner is preparing for a change or managing failover. If you are troubleshooting propagation after a DNS change, remember that your own ISP resolver may be caching the old value until the TTL expires. Use the SOA record's serial number to confirm the authoritative server has the latest zone data. For email troubleshooting, query both MX and TXT (look for v=spf1) records together to understand the full mail routing and anti-spam configuration.

How DNS Became the Internet's Invisible Foundation

Before DNS was invented in 1983, every computer on the ARPANET relied on a single text file called HOSTS.TXT, maintained at the Stanford Research Institute and downloaded regularly by each connected machine. As the network grew, this approach became unworkable — the file was updated multiple times per day and the bandwidth cost of distributing it globally was already straining the network. Paul Mockapetris at USC Information Sciences Institute designed the DNS specification, published in RFC 882 and 883 in November 1983, creating the hierarchical distributed database we still use today.

The original DNS had no built-in security, a deliberate design choice to keep the protocol simple and fast. This omission eventually led to serious vulnerabilities: in 2008, security researcher Dan Kaminsky discovered a critical cache poisoning flaw that could allow attackers to redirect entire domains to malicious servers. The flaw affected virtually every DNS resolver in the world and required an unprecedented coordinated emergency patch release across all major vendors simultaneously — one of the largest coordinated security responses in internet history.

DNS now underpins far more than address resolution. Modern TXT records carry SPF policies that define authorised mail senders, DKIM public keys that authenticate email signatures, and domain control validation tokens that allow certificate authorities to verify domain ownership without any human interaction. The humble DNS query, which typically completes in under 50 milliseconds, has quietly evolved into a critical security and identity layer for the entire internet.

Advertisement