Domain to IP Lookup Tool Free

A DNS lookup translates a domain name (like example.com) into the IP addresses and other records that computers use to route traffic. This tool queries six record types — A, AAAA, CNAME, MX, NS, and TXT — to give you a complete picture of a domain's DNS configuration.

It sends queries directly from your browser to Cloudflare's DNS-over-HTTPS (DoH) service at 1.1.1.1. This means your queries never pass through our servers — they go straight from your browser to Cloudflare and back.

DNS records reveal a domain's hosting infrastructure, email providers, CDN usage, and security configuration. MX records show who handles email (Google Workspace, Microsoft 365, etc.), CNAME records expose CDN providers like Cloudflare or CloudFront, and TXT records contain SPF and DMARC policies that list authorized email senders.

SPF (Sender Policy Framework) is a TXT record that lists which servers are authorized to send email on behalf of a domain. It helps prevent email spoofing by letting receiving mail servers verify that an email came from an authorized source. This tool parses SPF records and shows you the authorized senders in plain English.

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do with emails that fail SPF or DKIM checks. A policy of "reject" means unauthorized emails should be blocked, "quarantine" means they should go to spam, and "none" means no action is taken (monitoring only).

The tool uses two complementary methods. First, it examines DNS records — CNAME chains and NS records — for patterns associated with known CDN providers. For example, a CNAME pointing to something.cloudfront.net indicates AWS CloudFront. Second, it analyzes HTTP response headers from the domain's web server, looking for signatures like the cf-ray header (Cloudflare), x-served-by (Fastly), or x-amz-cf-id (CloudFront). Combining DNS and header analysis gives a more complete picture than either method alone.

No. When a domain uses a CDN or reverse proxy like Cloudflare, the A record points to the CDN's edge servers, not the origin server. The real IP is hidden by design. Historical DNS records (not available in this tool) or other OSINT techniques may help uncover origin IPs.

HTTP header analysis inspects the response headers a web server sends back when you request a page. These headers often reveal infrastructure that DNS records alone cannot — such as the specific CDN serving the content, caching policies, server software, and security configurations. For example, a domain might use Cloudflare DNS but serve content through a different CDN, which only the HTTP headers would reveal.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that responses have not been tampered with in transit. When the tool shows a green "DNSSEC" badge, it means the domain's DNS responses are cryptographically validated. "No DNSSEC" means the domain does not use DNS signing — which is common but leaves the domain more vulnerable to DNS spoofing attacks.

Confidence levels indicate how reliably a provider was identified from the HTTP headers. "High" means a definitive, provider-specific header was found (e.g. cf-ray for Cloudflare). "Medium" means a strong indicator was present but could theoretically appear in other configurations. "Low" means the detection is based on a general pattern that suggests but does not confirm a specific provider.

Yes. DNS queries go directly from your browser to Cloudflare's DoH endpoint. The HTTP header check is performed by a lightweight proxy that fetches the domain's response headers and returns them — it does not store queries or results. The domain you look up and the DNS results are processed entirely in your browser.

Not necessarily. The IP from an A record shows the outermost layer of infrastructure — which might be a CDN edge node, reverse proxy, WAF, or load balancer rather than the actual hosting server. For example, a domain might resolve to a Microsoft Azure IP while the website content is actually served by Cloudflare behind the scenes. Check CNAME chains, HTTP response headers, and TLS certificates to uncover the full hosting chain.

DNS standards don't allow CNAME records at the domain apex (e.g., example.com without www). This means the root domain must use an A record, which may point to older infrastructure, while the www subdomain can use a CNAME pointing to a newer host. Differences between root and subdomain resolution often indicate a layered setup or a migration in progress.

Multi-resolver comparison queries three independent DNS resolvers — Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) — for the same domain in parallel. If all resolvers return the same A records, the domain likely has a single, stable IP configuration. If they disagree, the domain may use DNS-based load balancing, anycast routing, or geo-DNS, which intentionally returns different IPs depending on the resolver's location.

The subdomain check probes 10 common subdomains — mail, ftp, api, dev, staging, admin, vpn, webmail, remote, and portal — for A and CNAME records. These subdomains often reveal additional services and infrastructure. For example, "mail" may point to the email server, "api" reveals backend services, and "staging" or "dev" subdomains may expose test environments that are not intended to be public.

The TLS certificate section shows the certificate issuer (e.g. Let's Encrypt, DigiCert, Cloudflare), the subject, validity dates, days until expiry, the TLS protocol version, and Subject Alternative Names (SANs). SANs are particularly useful for OSINT — they list all domain names covered by the same certificate, which can reveal related domains, subdomains, or services operated by the same organization.

Bulk lookup lets you enter up to 50 domains at once (one per line or comma-separated). The tool processes them with a concurrency limit of 5, running the same full DNS analysis on each domain. Results appear in tabs so you can switch between domains and compare their DNS configurations side by side.

Reverse DNS maps an IP address back to a hostname using PTR records. While forward DNS translates a domain to an IP, reverse DNS does the opposite. For investigators, PTR records can reveal the actual server hostname behind an IP — which may differ from the domain you queried. For example, an IP might resolve to a hostname containing "cloudflare" or "amazonaws", confirming the hosting provider.

The SOA (Start of Authority) record identifies the primary nameserver for a domain's DNS zone and the administrator's email address. It also contains the serial number (used to track zone file changes) and timing parameters for how secondary nameservers sync with the primary. For investigators, the SOA record can reveal the DNS hosting provider and sometimes the organization managing the domain's DNS.

OSINT pivot links are quick-access shortcuts to external investigation tools. This tool provides one-click links to the Wayback Machine (historical snapshots), VirusTotal (threat intelligence), Shodan (exposed services), crt.sh (certificate transparency logs), SecurityTrails (historical DNS data), BuiltWith (technology stack), URLScan.io (live page scanning), AlienVault OTX (threat intel), and Censys (internet-wide scanning). These tools provide additional context that complements the DNS and infrastructure data shown here.

The redirect chain traces the path from the initial HTTP request to the final destination URL. It reveals each intermediate redirect (301, 302, etc.) along the way. This is useful for understanding how traffic is routed — for example, whether HTTP redirects to HTTPS, whether the root domain redirects to www (or vice versa), and whether additional intermediaries like CDN edge servers are involved in the redirect path.

Typosquatting detection generates variations of the queried domain — character swaps, missing characters, doubled characters, homoglyphs (lookalike characters from other alphabets), and TLD swaps — then checks if those variants resolve to an IP address. Registered variants may be legitimate related domains, but they can also be used for phishing, brand impersonation, or credential theft. This scan is triggered manually to avoid excessive DNS queries.

Subdomain takeover occurs when a DNS CNAME record points to a third-party service (like Heroku, GitHub Pages, or AWS S3) that has been decommissioned. If the CNAME target returns NXDOMAIN, an attacker can claim that service name and serve malicious content on the subdomain. This tool checks all discovered CNAME records against known vulnerable service patterns and flags those that return NXDOMAIN.

RFC 7208 limits SPF to 10 DNS lookups during evaluation. Each "include:" and "redirect=" mechanism triggers a lookup, and these can chain recursively. If the total exceeds 10, receiving mail servers may return a "permerror" result, effectively disabling SPF protection. The SPF walk feature traces the full include tree and counts total lookups to flag domains that exceed or approach the limit.

The audit evaluates seven key security headers: HSTS (forces HTTPS), Content-Security-Policy (prevents XSS), X-Frame-Options (prevents clickjacking), X-Content-Type-Options (prevents MIME sniffing), Referrer-Policy (controls information leakage), Permissions-Policy (restricts browser features), and Access-Control-Allow-Origin (CORS configuration). Each header is scored as pass, warning, or fail with specific recommendations.

The blocklist check queries four major DNS-based blocklists — Spamhaus ZEN, SURBL, Barracuda, and SpamCop — for each resolved IP address. If an IP is listed, it may indicate the IP has been associated with spam, malware, or other abuse. Being listed on a blocklist can affect email deliverability and reputation.

Dangling DNS detection checks whether the targets of CNAME, MX, and NS records actually resolve to IP addresses. If a target returns NXDOMAIN, the record is "dangling" — pointing to a non-existent host. Dangling NS records are critical (the domain loses DNS resolution), dangling MX records mean email delivery fails, and dangling CNAMEs can enable subdomain takeover attacks.

RDAP (Registration Data Access Protocol) is the modern replacement for WHOIS. It returns structured registration data including the registrar, registration and expiration dates, and registrant information. Many domains use privacy protection services that redact registrant details, but the registrar name and dates are always available. An expiration date within 30 days is flagged as a warning.

A favicon hash is a MurmurHash3 fingerprint of a website's favicon.ico file. Shodan indexes these hashes, so searching for a specific hash reveals all servers on the internet using the same favicon. This is a powerful technique for finding related infrastructure, mirror sites, or servers running the same application — even if they use different domain names.

The robots.txt file tells search engine crawlers which paths to avoid. For investigators, the disallowed paths often reveal hidden or sensitive areas of a website: admin panels, API endpoints, backup directories, and authentication pages. This tool categorizes each path and highlights notable findings like admin panels or development environments.

SPF flattening resolves all include: and redirect= mechanisms in an SPF record down to their final IP addresses, producing a single flat SPF record with only ip4: and ip6: mechanisms. This eliminates DNS lookups during email delivery and avoids the RFC 7208 10-lookup limit. The flattened record can be copied and used as a replacement if the original SPF exceeds the lookup limit.

DKIM key strength analysis examines the public key in each DKIM DNS record to estimate the RSA key length. Keys of 512 bits are critically weak and can be cracked. 1024-bit keys are considered weak by modern standards. 2048-bit keys are the recommended minimum, and 4096-bit keys provide excellent security. The analysis helps identify domains with outdated DKIM configurations.

Technology stack detection analyzes HTTP response headers to identify the web server (Nginx, Apache, IIS), frameworks (Express, ASP.NET, Next.js), CMS platforms (WordPress, Drupal, Shopify), CDNs (Cloudflare, Fastly, CloudFront), and WAFs in use. Each detection includes a confidence level based on how specific the header signature is.

The cookie security audit inspects Set-Cookie headers for three critical security flags: Secure (cookie only sent over HTTPS), HttpOnly (cookie inaccessible to JavaScript, preventing XSS theft), and SameSite (prevents cross-site request forgery). Each cookie is scored 0-100 based on flag presence. Missing flags indicate potential security weaknesses in the application.

The email deliverability score is a composite rating (0-100) based on 9 factors: SPF record presence and quality, DKIM selector presence and key strength, DMARC policy and reporting configuration, MTA-STS enforcement, BIMI record with logo, and MX record presence. A high score means the domain's email authentication is well-configured, improving inbox delivery rates.