Webmaster & Network·4 min read

How DNS Resolution Works: Domain to IP, Explained

Type a name, get a number back. That exchange sits under every web request, yet most people only think about it when something breaks. Once you know how DNS resolution works, a confusing outage becomes a pipeline you can check: a domain either resolves to the address you expect or it does not, and either answer moves you forward. This piece stays narrow: the name-to-address question, what multiple results mean, and how far an IP can take you toward knowing who serves a site.

Open the free Domain to IP Lookup All insights

The question a domain to IP lookup answers

Which server picks up?

The support ticket says the site is down. Your monitoring says it is fine. Before anyone blames the server, ask a sharper question: which machine is the domain sending people to? Resolving the name answers exactly that. If it points at an address nobody recognises, the problem is not the server, it is the record pointing at the wrong one.

The same narrow question comes up with firewall allowlists, SSH configs that need a raw address, and spot checks after a hosting move, where you just want to see the new address answering under the name.

How the lookup chain works before an IP comes back

Root, TLD, authoritative.

A resolver walks a hierarchy. It asks a root server which servers handle the top-level domain, asks those for the domain's authoritative nameservers, then asks the authoritative servers for the address records: A records for IPv4 and AAAA records for IPv6.

Caching shortcuts most of that in practice. Each answer carries a TTL, and resolvers reuse it until it expires, which is why two people can get different addresses for the same domain minutes after a change. When you press Resolve, Domain to IP Lookup asks the resolver you pick, Google Public DNS by default, and shows the TTL next to every address. In a cached answer that number counts down, so it can be lower than the value set in the zone.

A resolved domain, read column by column

A worked example.

Resolve example.com and you might see two IPv4 addresses, 203.0.113.42 and 203.0.113.43, each with a TTL of 300, and one IPv6 address, 2001:db8:4400::17. The Network owner column names a hosting company and the Country column shows where that range is registered or used.

Several A records are deliberate redundancy. Resolvers rotate through them, spreading visitors across two machines and surviving the loss of either one. The single AAAA entry means the site is reachable over IPv6 as well. If the IPv6 column read None instead, nothing is broken; the domain simply has no AAAA record yet, which is still common. A TTL of 300 tells you changes to this record will spread within about five minutes.

When the address belongs to a CDN

The IP may not be the host.

Many sites sit behind a content delivery network. Visitors connect to the nearest edge server, and the CDN fetches pages from the origin server behind it. DNS then returns the CDN's addresses, so the lookup shows who serves the traffic, not where the site is hosted.

The tool spots this from a CNAME that points at a known CDN hostname and from the network that owns the IP. It flags Cloudflare, CloudFront, Akamai, Fastly and several others, and shows the CNAME chain when there is one. In that case the owner and country columns describe the CDN, and the origin address stays private by design.

One address, many domains

Shared hosting is normal.

Resolve a dozen small business domains and several will land on the same address. Shared hosting works because the server picks the right site from the hostname inside the request, not from the address it arrived on. Hundreds of unrelated sites can share one machine.

This cuts both ways. You cannot assume two domains on one address are related, and you cannot block an address without hitting every site behind it. Mail administrators feel this most, since one spammy tenant on a shared address can hurt deliverability for its neighbours.

Domain to IP conclusions that turn out wrong

The lookup is simple. The interpretation is where people slip:

Treating a CDN edge address as the origin server. When the CDN notice appears, the real server is somewhere else.
Hardcoding a resolved address into configs. CDN and cloud addresses change, and today's answer can stop working next month.
Ignoring the IPv6 column, then chasing a bug that only affects visitors whose networks prefer IPv6.
Reading a shared address as proof that two domains belong to the same owner.
Forgetting that www.example.com and example.com can point to different addresses. The tool resolves exactly the hostname you give it.

Getting more out of a resolved IP

The Network owner column usually names the hosting company, cloud provider or CDN that announces the address range, which is often all you need to know who hosts a site. It will not name the customer, and a small host renting space in someone else's data center may show up under the data center's name.

For several sites at once, open the Bulk tab, paste up to 50 domains or URLs one per line and press Resolve all. The table can be downloaded or copied as CSV, which is handy for checking a portfolio of client sites after a hosting move. And when a result surprises you, run a full record query, since a CNAME in the chain often explains an address you did not expect.

When to use DNS Lookup instead

Narrow tool, narrow job.

Domain to IP Lookup is the focused instrument: name in, addresses out, with owner, country and CDN details. Use it when the address is the whole question. When you need MX entries, TXT verification strings or nameserver data, switch to DNS Lookup, which queries nine record types in one pass.

Two other tools complete the picture. What Is My IP Address shows the address you present to the world, useful when you are allowlisting yourself on the server you just resolved, and WHOIS Lookup covers who registered the domain in the first place.

Try it now

Open Domain to IP Lookup

The tool is one click away. No sign up, no upload, no payment.

Open Domain to IP Lookup

Write a review