What is a DNS A record?

An A record (Address record) maps a domain name to an IPv4 address. When you type a URL, your browser performs a DNS lookup to find the A record and connect to that IP address.

What is the difference between A and AAAA records?

A records map to IPv4 addresses (e.g., 93.184.216.34). AAAA records map to IPv6 addresses (e.g., 2606:2800:220:1:248:1893:25c8:1946). Most modern websites have both.

What is a CNAME record used for?

A CNAME (Canonical Name) record aliases one domain name to another. For example, www.example.com might CNAME to example.com. The browser then looks up the target domain's A record to find the IP address.

Is this tool free to use?

Yes, this tool is completely free with no hidden charges, sign-up requirements, or usage limits. Use it as often as you need.

Does this tool work offline?

No. DNS lookups require a live network connection to the Cloudflare DNS-over-HTTPS endpoint. The UI itself runs in your browser, but the actual DNS query needs internet access.

Free DNS Lookup

Query DNS records for any domain using Cloudflare DNS-over-HTTPS.

Domain Name

DNS Record Types Explained

A · Maps domain to IPv4 address

AAAA · Maps domain to IPv6 address

CNAME · Alias pointing to another domain

MX · Mail exchange servers (with priority)

TXT · Arbitrary text (SPF, DKIM, domain verification)

NS · Nameservers authoritative for the domain

SOA · Start of authority, primary nameserver info

PTR · Reverse DNS, maps IP back to domain

How It Works

Enter a domain: Type any domain name (including subdomains) into the input field.
Select record types: Choose which DNS record types to query: A, AAAA, MX, CNAME, TXT, NS, SOA, or all of them.
View results: Results are fetched from a public DNS-over-HTTPS provider and displayed with TTL values and record data.
Diagnose issues: Compare results from different record types to identify misconfiguration, propagation delays, or missing records.

Why Use DNS Lookup?

DNS issues are among the most common causes of website downtime, email delivery failures, and domain migration problems. Being able to query DNS records directly from the browser, without using command-line tools like dig or nslookup: is valuable for developers, DevOps engineers, and sysadmins. This tool queries records via DNS-over-HTTPS for privacy and firewall bypass. Use it to verify MX records after changing email providers, confirm A/CNAME records after a DNS migration, check TXT records for SPF/DKIM email authentication, and diagnose propagation delays.

DNS Record Types

A: IPv4 address for a domain
AAAA: IPv6 address for a domain
MX: mail server records for email routing
CNAME: canonical name alias pointing to another domain
TXT: text records for SPF, DKIM, domain verification
NS: authoritative nameservers for the domain

40 years of DNS: from RFC 882 to DNS over QUIC

The Domain Name System was designed by Paul Mockapetris at USC/ISI and specified in RFC 882 and RFC 883 (November 1983), replacing the flat HOSTS.TXT file that the ARPANET had outgrown. The system was overhauled and formalised in RFC 1034 and RFC 1035 (November 1987), the documents still cited today. Jon Postel coordinated the assignment of the original 13 root nameservers, labelled a.root-servers.net through m.root-servers.net, a count fixed not by capacity but by the 512-byte UDP packet size limit of the era. Two major shocks reshaped DNS in this century. In July 2008, Dan Kaminsky disclosed a cache-poisoning attack that let attackers inject forged records into resolvers within seconds. The industry responded with a coordinated patch (source-port randomisation) and renewed interest in DNSSEC (RFC 4033-4035, March 2005), which signs records cryptographically. The second shock was privacy: queries travelled in plaintext on UDP port 53 for 35 years. DNS over TLS (DoT, RFC 7858, May 2016) wraps queries in TLS on port 853. DNS over HTTPS (DoH, RFC 8484, October 2018) tunnels queries through HTTPS on port 443, hiding even the fact that DNS is happening. DNS over QUIC (RFC 9250, May 2022) is the latest, using the same transport that powers HTTP/3. Public resolvers 1.1.1.1 (Cloudflare, launched April 1, 2018), 8.8.8.8 (Google Public DNS, December 2009), and 9.9.9.9 (Quad9, November 2017) all support DoH and DoT today.

Record types in depth

A (RFC 1035). 32-bit IPv4 address. One domain can have many A records for load balancing; resolvers rotate through them (round-robin DNS).
AAAA (RFC 3596, 2003). 128-bit IPv6 address. Pronounced «quad-A». As of 2024, around 45% of Google's traffic is IPv6.
CNAME (RFC 1035). Alias: «follow this name and look up its records instead». Cannot coexist with any other record at the same name. This is why example.com cannot have both a CNAME and an MX or A record at the apex; modern alternatives use ALIAS or ANAME (vendor-specific) or HTTPS records (RFC 9460, 2023).
MX (RFC 1035, updated by RFC 7505 «null MX»). Mail exchange server with a priority value. Lower priority is preferred; ties are randomised. 0 . (RFC 7505, June 2015) explicitly says «this domain receives no mail», blocking spam to non-mailbox domains.
TXT (RFC 1035). Free-form text strings. Now carries critical authentication: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), and ownership verification for Google Search Console, Microsoft 365, ACME (Let's Encrypt) DNS-01 challenges.
NS (RFC 1035). Names of the authoritative nameservers. Always at least two for redundancy. The «glue records» in the parent zone provide IPs so a recursive resolver can reach the nameserver without circular lookups.
SOA (RFC 1035). Start of Authority. Single record per zone listing the primary nameserver, admin email (with first . replaced by @), serial number (incremented on changes), refresh, retry, expire, and minimum TTL.
CAA (RFC 8659, 2019; originally RFC 6844, 2013). Certificate Authority Authorisation. Lists which CAs are allowed to issue certificates for the domain. Mandatory check by CA/Browser Forum baseline requirements since September 2017.
SRV (RFC 2782, 2000). Service location: protocol, priority, weight, port, target host. Microsoft Active Directory, XMPP, SIP, Matrix federation all use SRV records for service discovery.
PTR (RFC 1035). Reverse DNS. Maps an IP back to a domain. Lives in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones. Required by many mail servers to accept email; missing PTR is a common spam signal.
DNSKEY / DS / RRSIG (RFC 4034-4035). DNSSEC plumbing. The DNSKEY publishes the zone's signing keys; DS in the parent zone is the cryptographic «here is the next link in the chain» pointer; RRSIG carries the actual signature for each record set.

Where DNS lookup actually helps

Setting up email on a new domain. Verify MX records point to the right provider (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Check SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
Domain migration and propagation. After updating nameservers at the registrar, query both the old and new authoritative servers to confirm the change has propagated globally. Different resolvers cache for different durations (the TTL is hint, not contract).
TLS / SSL certificate troubleshooting. The ACME DNS-01 challenge used by Let's Encrypt and similar requires placing a TXT record at _acme-challenge.example.com. Check the value before triggering certificate issuance to avoid wasted rate-limit attempts.
Detecting subdomain takeover risk. A CNAME pointing to an unregistered service (Heroku app deleted, S3 bucket released) lets attackers register it and serve content on your subdomain. Quick CNAME audit catches dangling pointers.
CDN and load-balancer verification. Confirm a domain CNAMEs to the right Cloudflare, Fastly, Akamai, CloudFront, or Vercel endpoint after deployment. Detect when staging accidentally points to production.
Geographic DNS comparison. Some sites serve different A records by region (GeoDNS). Querying from different DoH endpoints (Cloudflare 1.1.1.1 vs Google 8.8.8.8) hints at how a user in Frankfurt vs Mumbai sees the site.
Security and incident response. Look for unexpected NS records (registrar hijack), suspicious TXT records, or recently-added MX records. Use the SOA serial to track when a zone last changed.

DNS mistakes that break sites and email

CNAME at the apex. RFC 1034 forbids putting a CNAME on example.com itself (only on subdomains like www.example.com). Cloudflare, Route 53, DNSimple work around this with CNAME flattening or ALIAS records; Vercel, Netlify use HTTPS service binding records (RFC 9460). Trying it on a bare-bones registrar's DNS panel silently breaks email.
Forgetting to lower TTL before a migration. If your A record has TTL 86400 (24 hours) and you change it the morning of the switchover, resolvers worldwide will keep handing out the old IP for up to a day. Drop TTLs to 300 seconds a few days before the change.
SPF record with too many DNS lookups. RFC 7208 caps SPF at 10 DNS lookups per evaluation. Chain too many include: directives and your SPF record fails with permerror, which DMARC treats as a failure. Flatten or consolidate with tools like SPF Surveyor.
Dangling CNAME after service teardown. Deleted the Heroku app but the app.example.com CNAME still points to example.herokuapp.com? Anyone can register that app name and host their content on your subdomain. Audit and remove orphaned CNAMEs.
No CAA record. Without a CAA record, any CA in the WebPKI (~50 worldwide) can issue a certificate for your domain. Lock it to one or two trusted CAs: 0 issue "letsencrypt.org". Mandatory CA check since September 2017.
Wildcard records masking missing entries. A *.example.com A record makes every typo subdomain resolve, hiding real configuration mistakes. Combine carefully with explicit MX rules to avoid spam to typo addresses.
Mixing DNSSEC and unsigned zones during cutover. Enabling DNSSEC at the registrar before the new nameservers serve signed records produces a SERVFAIL for every validating resolver (Cloudflare 1.1.1.1, Quad9). Always sign first, then publish the DS record.

More frequently asked questions

Why does this tool sometimes return different results than dig?

Two main reasons. First, this tool queries via DNS over HTTPS through Cloudflare's 1.1.1.1 resolver, while dig on your laptop queries whatever resolver you have configured (often your ISP). Different resolvers cache for different durations and may have stale data. Second, EDNS Client Subnet (ECS, RFC 7871) sends a hint about your network to authoritative servers, which can return GeoDNS-tailored answers; Cloudflare 1.1.1.1 explicitly strips ECS for privacy, so geo-targeting sees you as «coming from Cloudflare» rather than your real location. dig +short on a residential ISP will often see the GeoDNS-personalised result.

What's the difference between authoritative and recursive resolvers?

Authoritative resolvers hold the master copy of a zone (Cloudflare DNS, Route 53, DigitalOcean DNS, etc.) and answer only for the domains they're configured for. Recursive resolvers (1.1.1.1, 8.8.8.8, your ISP) take queries from clients and walk the DNS tree on their behalf: root → TLD → authoritative. They cache answers up to the TTL, which is why a record change can take time to «propagate». This tool talks to a recursive resolver (Cloudflare 1.1.1.1), so the answer you see is the cached view that recursive resolver currently holds.

How long does DNS propagation actually take?

«Propagation» is a misnomer: DNS doesn't push updates, recursive resolvers around the world simply keep cached copies until their TTL expires. If your existing A record had a TTL of 300 seconds, every cache will refresh within 5 minutes. If it was 86400 (24 hours, a common default), worst-case is 24 hours. Some misbehaving resolvers ignore TTL and cache longer; some over-eager browsers and OSes cache locally too (Chrome's internal DNS cache lasts 1 minute). Drop TTL low before a planned change, then raise it again afterward.

Is DNS over HTTPS really «private»?

It hides queries from your ISP and from on-path observers on Wi-Fi, but the resolver you choose can still see every query. Trust shifts from your ISP to whoever runs the DoH endpoint (Cloudflare, Google, Quad9, NextDNS). Some, like Cloudflare 1.1.1.1, publish independent audits of their no-logs policy; others don't. DoH also doesn't hide the IP address you ultimately connect to, your subsequent TLS handshake's SNI field reveals the destination domain to network observers, until ECH (Encrypted Client Hello, RFC 9180) is universally deployed. As of 2024, ECH is supported by Cloudflare, Firefox, Chrome (behind a flag) but not yet ubiquitous.

Why do I need a network connection if this is a «browser-based» tool?

The UI runs entirely in your browser (no proprietary code on our server), but DNS lookup itself is by definition a network operation: it queries a remote authoritative or recursive nameserver. This tool sends a single HTTPS request per lookup to Cloudflare's public 1.1.1.1 DoH endpoint at cloudflare-dns.com/dns-query. The domain you query is visible to Cloudflare; nothing else (no IP, no fingerprint) is sent.