Domain to IP Lookup

What "resolving a domain to an IP" actually means

When you type example.com into a browser, your computer asks a DNS resolver: "what IP address answers this name?" The resolver walks a chain — root servers → TLD servers → authoritative servers — and returns the IP that the domain owner has configured. That whole conversation usually completes in 20–80 milliseconds. This tool short-circuits the chain and asks Cloudflare's public DNS-over-HTTPS resolver (1.1.1.1) directly, so the answer is what a fresh client would see — no caching by your ISP, no stale local entry, no VPN interference.

The result you get back is more than a single IP. Modern DNS records cover several record types, each answering a different question:

• A record — the IPv4 address (e.g. 93.184.216.34). This is what most people mean by "the domain's IP".
• AAAA record — the IPv6 address (e.g. 2606:2800:220:1:248:1893:25c8:1946). Modern infrastructure usually has both; if AAAA is missing, IPv6-only clients will fail.
• CNAME record — an alias pointing to another domain. CNAMEs are how SaaS vendors give you app.yourcompany.com → vendor.example.com without exposing their IPs.
• MX record — the mail server for the domain. If you receive bounces, MX is where to look first.
• TXT record — free-form text. Used for SPF, DMARC, DKIM, domain ownership verification (Google, Stripe, Twilio), and BIMI.
• NS record — the authoritative name servers. Tells you which DNS provider hosts the zone (Cloudflare, AWS Route 53, Google Cloud DNS, GoDaddy).
• CAA record — Certificate Authority Authorization. Lists which CAs may issue TLS certificates for the domain. A wrong CAA can break HTTPS deployments.

Why this is different from dig or nslookup

dig and nslookup on your laptop usually go to whatever resolver your network configured — your ISP, your office firewall, or whatever your VPN injected. Those resolvers cache. They sometimes lie. Captive portals on coffee shop Wi-Fi rewrite NXDOMAIN responses into ad pages. By going through Cloudflare DoH, this tool gives you what the public internet actually sees — which is what your users see. If your DNS change isn't showing up in dig, check here. If it shows up here but not dig, the problem is your local resolver.

How to read the answer

The hero panel shows the primary A and AAAA results — those are the IPs a browser would connect to right now. Below that, every record type we queried is listed in its own section, with each record's TTL (time-to-live) so you know how long the answer is cached. A short TTL (60–300 seconds) is a sign the operator expects to make changes; a long TTL (3600+) means the record is stable and a change you make will take a while to propagate worldwide.

If you see a CNAME chain — for example, app.example.com → app-prod.cdn.example.com → 12.34.56.78 — the actual IP at the end is what serves the request. CNAMEs add latency on the first lookup but are cached by recursive resolvers, so the cost is one-time per TTL window.

Common patterns and what they tell you

• A record points to 104.21.x.x or 172.67.x.x → the domain is on Cloudflare. Your real origin is hidden behind Cloudflare's reverse proxy.
• A record points to 76.76.21.x → Vercel.
• A record points to 185.199.108–111.x → GitHub Pages.
• NS records contain aws-dns → AWS Route 53 hosts the zone.
• NS records contain cloudflare.com → the zone is on Cloudflare DNS (regardless of where origin runs).
• MX record is aspmx.l.google.com → Google Workspace email.
• MX record is outlook.com → Microsoft 365.
• TXT record starts with v=spf1 → SPF policy. Use the email checker to grade it.
• TXT record starts with v=DMARC1 → DMARC policy. Same.

What this tool cannot tell you

• Whether the IP is reachable. An A record might point to an IP, but the server behind it might be offline. Use ping or check-host.net for reachability.
• What runs at the IP. The DNS answer is just an address. Use DNSDumpster or run a port scan if you own the asset.
• Geolocation. The IP block reveals an approximate region, but anycast IPs (Cloudflare, Google, Fastly) appear in many regions at once. IPinfo gives a rough geographic guess.
• Historical DNS. We show what DNS returns right now. For historical records, paid services like SecurityTrails or DNSMap store snapshots.
• Reverse DNS (PTR). Reverse lookups (IP → name) need a different query path; we don't run them automatically because most IPs don't have a meaningful PTR.

Caching, propagation, and why DNS changes "don't take effect"

If you've just updated a record and don't see it here, the issue is almost always TTL. When you change a record, every recursive resolver between you and the user keeps the old answer until its TTL expires. Cloudflare's resolver (this tool's source) usually catches up within a minute or two. Your ISP might take an hour. Mobile carriers can be appalling — multi-hour propagation is common. Browsers, OS resolvers, and apps each add their own caches on top.

To verify a change has propagated globally, check more than one resolver. whatsmydns.net queries dozens of locations at once. If they all agree, the change is live; if they disagree, you're mid-propagation.