How to Find a Domain's IP Address — Step by Step

A domain name like cloudflare.com is a label. The internet doesn’t actually route traffic to labels — it routes traffic to IP addresses. So somewhere between the moment you type a URL and the moment the page loads, that label has to be translated into one or more IPs.

If you’ve ever needed to know “what’s the IP behind this hostname?” — for a firewall rule, a connectivity test, a security investigation, or just plain curiosity — this guide covers the five practical ways to do it, the gotchas with each, and when each one is the right tool.

Why Bother Looking Up the IP?

A few real reasons people need to resolve a domain to an IP:

• Firewall rules. Allowing a specific outbound destination by hostname is fragile — most enterprise firewalls want an IP or CIDR. You resolve the name, then add the IP to the allow-list (and update it when it changes).
• Connectivity testing. When ping example.com fails, the first question is: did DNS even resolve, or is the IP unreachable? Resolving the IP manually separates the two.
• Security investigations. Tracing a phishing link or a callback URL to its hosting infrastructure starts with the IP.
• CDN debugging. A single hostname can return different IPs depending on where you’re querying from. Figuring out which CDN node is serving you starts here.
• Multi-region routing. Some services use DNS-based geo-routing. You can confirm you’re hitting the regional endpoint you expect by resolving the name from each region.

Whatever the reason, the underlying job is the same: ask DNS, get an IP. The interesting part is that a single domain can have many IPs, can return different IPs to different clients, and the IP can change at any moment if the operator has a short TTL.

Method 1: dig (macOS / Linux / WSL)

dig is the canonical command-line DNS lookup tool. It ships with most Unix-like systems. To resolve a domain to its IPv4 address:

dig +short cloudflare.com A

The +short flag strips the verbose output. The A asks specifically for IPv4 records. To get IPv6:

dig +short cloudflare.com AAAA

The two are independent. Many domains have both — cloudflare.com returns several IPv4 addresses and several IPv6 addresses. Your client picks one based on its address family preference (typically IPv6 first if both are available, which is called “Happy Eyeballs”).

For a fuller picture without +short:

dig cloudflare.com

You’ll see TTLs (how long resolvers should cache the answer), the authoritative section, and timing info. Useful when you need more than just the address.

To query a specific resolver instead of your default:

dig @1.1.1.1 cloudflare.com A

This is how you confirm that an unexpected answer isn’t your local resolver doing something weird. If 1.1.1.1 and 8.8.8.8 both return the same thing, the issue is authoritative or upstream.

Method 2: nslookup (Windows / cross-platform)

nslookup is older and less featureful than dig, but it ships everywhere. On Windows it’s the easiest option:

nslookup cloudflare.com

That returns the IPs from your configured DNS server. To use a specific server:

nslookup cloudflare.com 1.1.1.1

To ask for a specific record type:

nslookup -type=AAAA cloudflare.com

If you’re writing automation or doing serious investigation, prefer dig where you can. But for “I just need the IP,” nslookup is fine and present by default on almost every machine.

Method 3: PowerShell on Windows

Windows has a more modern option built into PowerShell:

Resolve-DnsName cloudflare.com -Type A

This is the closest thing to dig that ships with Windows out of the box. It supports all the record types you’d expect (A, AAAA, MX, TXT, NS, etc.) and returns structured objects you can pipe into other commands. For scripts that need to react to the result programmatically, this is the better choice than parsing nslookup output.

Method 4: Programmatic Lookups in Code

If you’re doing the lookup as part of an application — not at a terminal — every major language has standard library DNS resolution. Worth knowing because the defaults of these libraries vary significantly.

Node.js:

const dns = require('node:dns').promises
const addresses = await dns.resolve4('cloudflare.com')
console.log(addresses)  // ['104.16.132.229', '104.16.133.229', ...]

Node’s dns.resolve4 / dns.resolve6 go directly to the configured DNS server, skipping /etc/hosts. If you want the same lookup the OS would do (including hosts file and any platform-specific behavior), use dns.lookup() instead.

Python:

import socket
addresses = socket.gethostbyname_ex('cloudflare.com')
print(addresses[2])  # list of IPs

socket.gethostbyname_ex returns the canonical name, aliases, and all IPv4 addresses. For IPv6 you need socket.getaddrinfo with explicit family flags. There’s also the third-party dnspython library if you want full control.

Go:

ips, err := net.LookupIP("cloudflare.com")

This returns both IPv4 and IPv6 addresses, which you then filter as needed. Go’s stdlib is solid for DNS — no third-party libraries required for normal use.

PHP:

$ip = gethostbyname('cloudflare.com'); // single IPv4
$all = dns_get_record('cloudflare.com', DNS_A);

gethostbyname is the simple version (one address only, IPv4-only). dns_get_record is the powerful version with TTLs and the ability to query specific types.

Method 5: Browser-Based Tools

When you’re not at a terminal — on a phone, in a meeting, on a managed workstation — a browser tool is the fastest path. Our Domain to IP lookup takes a domain and returns the resolved IPs with geo data attached (country, ISP, ASN). That last part matters: knowing the IP is half the story. Knowing whose IP it is often matters more, and that’s where IP geolocation picks up.

If you need to do both at once — resolve the name AND learn about the resulting IP — a browser tool that bundles both saves a step.

The Gotchas Nobody Mentions

A domain can have many IPs.

Most major services return multiple A records, and the client picks one (round-robin, latency-based, or otherwise). When you say “the IP of cloudflare.com,” there isn’t a single answer. The answer is a set.

The IP you get depends on where you ask.

CDNs and geo-routed services return different IPs to clients in different regions. The IP you see resolving from your laptop might not be the IP a user in Singapore sees. For CDN debugging, run the lookup from multiple geographic vantage points or use online tools that do exactly this.

TTLs control freshness.

The TTL on a record (in seconds) is how long your resolver and downstream caches will hold the answer. A high TTL (86400 = 24 hours) means changes take up to a day to be visible everywhere. A low TTL (60 seconds) means changes propagate quickly but DNS load is higher.

Wildcard records exist.

*.example.com can match any subdomain that isn’t explicitly defined. So notarealsubdomain.example.com might resolve to a real IP if a wildcard is set up. Lookups don’t tell you “this is a wildcard match” — they just give you the IP.

CNAMEs add a hop.

If www.example.com is a CNAME for example.com, your resolver follows the chain transparently and you get the final A record. But for diagnostics — especially when something is broken — you sometimes need to see each hop. Use dig without +short to see the full chain.

The IP can change between when you check and when you connect.

This is why caching firewall rules by IP is fragile. The IP you resolved 10 minutes ago may no longer be authoritative. For long-lived rules, prefer hostname-based rules (where supported) or use CIDR ranges published by the provider rather than runtime DNS results.

What to Do With the IP Once You Have It

Resolving a domain to an IP is rarely the end goal. Usually it’s the start of something else:

• Identify the network operator. Run the IP through an ASN lookup to find the autonomous system (and therefore the ISP, hosting provider, or organization) that controls it.
• Geolocate it. Find the country, city, timezone, and other metadata via IP lookup or the Ip2Geo API.
• Reverse it. Run a PTR lookup (reverse DNS) to see what hostname the IP claims to be. Useful for mail servers and abuse tracking, less useful for CDN-hosted IPs (which usually don’t have meaningful PTRs).
• Investigate the routing. If you suspect a routing issue, traceroute to the IP shows you the hops between you and the destination. Each hop is a router with its own IP — and probably its own ASN, which you can look up.

Quick Reference

You’re on…	Use this
macOS / Linux terminal	dig +short example.com
Windows terminal	Resolve-DnsName example.com
Quick check from any OS	nslookup example.com
Phone / locked-down browser	Domain to IP tool
Inside Node.js code	dns.resolve4('example.com')
Inside Python code	socket.gethostbyname_ex('example.com')

The lookup itself is one command. The interesting parts — multiple IPs, geo-routed answers, CNAMEs, TTLs, the difference between what DNS says and what the IP actually is — are the rest of the story. If you find yourself doing this often as part of debugging or building, the right approach is to chain the lookup into IP geolocation so a single query gives you the IP and the network context behind it.