How to Find the IP Address of a Website or Domain

This guide shows you how to find the IP address that a website or domain resolves to: the numeric address, such as 203.0.113.10, that a name like yourdomain.com points at behind the scenes. Turning a name into an address is called a DNS lookup (you will also hear it called "resolving" a domain, or a "name resolution"), and every browser does it silently every time you open a page. You will want to do it yourself when you are confirming that a domain points at the right server, adding a server address to a firewall or allow-list, checking a change you made to your DNS, or working through a support ticket. There are two ways to do it: a browser-based lookup tool that needs nothing installed, and the command-line tools built into every operating system. Both are covered below, along with the one thing that surprises people most often: the address a lookup gives you is not always the real address of the server your site sits on. When a content delivery network (CDN) or reverse proxy sits in front of a domain, the lookup returns the CDN's address and hides the true origin by design. That gotcha, and how to read the output well enough to spot it, is what this article adds on top of the raw commands.

Last reviewed: 27 July 2026. This guide covers the standard DNS lookup tools built into Windows, macOS and Linux, namely ping, nslookup, dig and host, which are long-established and stable across versions. It is written for Noiz hosting and is kept current against the DNS standards and the tools' own documentation. It complements, and does not replace, the official documentation linked below. The example IP addresses used throughout (203.0.113.10 and 2001:db8::10) are reserved documentation addresses, not real servers, so replace them and yourdomain.com with your own values.

Official Documentation Reference

• RFC 1035: Domain Names, Implementation and Specification: the foundational DNS standard that defines the A record (the IPv4 address of a name) and the structure of the query and answer you see in a lookup.
• RFC 3596: DNS Extensions to Support IP Version 6: defines the AAAA record, which is how an IPv6 address is published for a name.
• nslookup (Microsoft Learn): the reference for the nslookup command that ships with Windows, including its interactive mode, the -type= option, and how to query a specific DNS server.
• dig and host manual pages (ISC BIND documentation): the authoritative reference for dig and host, including the meaning of every section in dig output and the flags such as +short.

Prerequisites

• The domain name you want to look up, for example yourdomain.com. You do not need to own it; a lookup reads public DNS.
• For the command-line methods, access to a terminal: Command Prompt or PowerShell on Windows, and Terminal on macOS or Linux. No administrator rights are needed for a plain lookup.
• A working internet connection. A lookup asks a DNS resolver a question over the network, so an offline machine cannot resolve a name it has not already cached.

The Quick Way: Online Lookup Tools

If you only need the answer once, or you are on a phone or a locked-down work machine where you cannot open a terminal, a browser-based DNS lookup is the fastest route. You type the domain into a web form and it shows the A record (IPv4) and, if one exists, the AAAA record (IPv6). Public DNS providers run such pages; the query page at dns.google, run by Google Public DNS, is one authoritative example, and a web search for "DNS lookup" returns several more.

One thing worth understanding about these tools: the lookup runs on the tool's own servers, not on your machine, so the answer is what a public resolver somewhere on the internet sees. That is usually the same as what you would see, but it means an online tool bypasses your local network's own DNS and any cached answer on your computer. That difference becomes useful later when a stale local cache is the problem.

Looking Up an IP on Windows

Windows ships with ping and nslookup, and modern Windows also has the PowerShell Resolve-DnsName cmdlet. It does not include dig or host. Open Command Prompt or PowerShell from the Start menu to use these.

ping: the fastest look, as a side effect

ping exists to test whether a host answers, but to do that it first resolves the name, and it prints the address it found on the very first line:

ping yourdomain.com

The first line reads something like Pinging yourdomain.com [203.0.113.10] with 32 bytes of data. The address in the square brackets is your answer. This works even when the replies that follow all time out, because many servers deliberately ignore ping; the name was still resolved to get that address in the first place, so do not be put off by "Request timed out" lines underneath. By default Windows will usually return an IPv4 address here; add -6 to ask for IPv6 (ping -6 yourdomain.com).

nslookup: the purpose-built tool

nslookup yourdomain.com

The output first names the DNS server it asked (the Server and Address lines at the top, which is your configured resolver), then, under Non-authoritative answer, gives the Name and one or more Addresses. "Non-authoritative" simply means the answer came from a resolver's cache rather than from the domain's own nameservers, which is normal and not a problem. To ask specifically for the IPv6 address, set the type:

nslookup -type=AAAA yourdomain.com

To ask a particular DNS server instead of your default one, add its address as a second argument. This is how you check what a public resolver sees, sidestepping your own network's DNS:

nslookup yourdomain.com 1.1.1.1

Resolve-DnsName: the tidy PowerShell option

In PowerShell, Resolve-DnsName presents the same information in clean columns of Name, Type, TTL and IPAddress, which many people find easier to read than nslookup:

Resolve-DnsName yourdomain.com
Resolve-DnsName yourdomain.com -Type AAAA

Looking Up an IP on macOS and Linux

macOS includes ping, nslookup, host and dig out of the box. On Linux, ping is always present, but dig and host come from a DNS utilities package (named dnsutils or bind-utils depending on the system) that you may need to install first. Open Terminal to use them.

host: the shortest command

host gives a one-line, plain-English answer and is the quickest to read:

host yourdomain.com

It replies with lines such as yourdomain.com has address 203.0.113.10 and, if the domain publishes IPv6, yourdomain.com has IPv6 address 2001:db8::10. It will also list where mail is handled, which you can ignore when you only want the web address.

dig: the tool that shows you everything

dig is the professional's tool because it shows the full DNS answer, not just the address. For a plain look at the IPv4 address:

dig yourdomain.com

By default this queries for the A record. To get only the address with none of the surrounding detail, add +short:

dig +short yourdomain.com

For the IPv6 address, ask for the AAAA record, and to query a specific resolver (here Cloudflare's public 1.1.1.1, though Google's 8.8.8.8 works just as well) put its address after an @:

dig yourdomain.com AAAA
dig @1.1.1.1 yourdomain.com

The ping command works the same as on Windows: the first line reports the resolved address before any reply. Use ping -6 yourdomain.com (or ping6 on older systems) for IPv6.

IPv4 and IPv6: A Records and AAAA Records

A domain can point at two kinds of address, and a lookup can return either or both. Knowing which you are looking at saves a lot of confusion.

• An A record maps a name to an IPv4 address: four numbers separated by dots, such as 203.0.113.10. This is still the most common answer.
• An AAAA record (spoken as "quad-A") maps a name to an IPv6 address: a longer address written in hexadecimal groups separated by colons, such as 2001:db8::10. IPv6 is increasingly common but not universal.

Most tools show the IPv4 (A) answer by default, so if you specifically want the IPv6 answer you must ask for AAAA, as shown above. If a domain has no IPv6 address, an AAAA query returns no answer at all: that is expected and is not a fault, it simply means the domain has not published an IPv6 record. Equally, a domain can have several A records at once, in which case a lookup lists more than one address, which is normal for larger sites and is covered in the next sections.

How to Read dig Output

A full dig response looks busy the first time you see it, but only one part is the answer and the rest is useful context. Here is a typical response, trimmed slightly, for dig yourdomain.com:

; <<>> DiG 9.x <<>> yourdomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;yourdomain.com.            IN      A

;; ANSWER SECTION:
yourdomain.com.     300     IN      A       203.0.113.10

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jul 21 12:00:00 2026
;; MSG SIZE  rcvd: 59

Read it top to bottom like this:

• The HEADER line carries the status. NOERROR means the query succeeded. NXDOMAIN means the name does not exist (a typo, an expired domain, or nameservers not yet set). SERVFAIL points at a problem on the resolver's side rather than with the domain.
• The QUESTION SECTION simply echoes what you asked: the name, class IN, and the record type A.
• The ANSWER SECTION is the payload, and this single line is what you came for. Reading it left to right: the name (yourdomain.com.), the TTL in seconds (300), the class (IN), the record type (A), and finally the value, 203.0.113.10. In plain terms, this line says the domain resolves to that address.
• The footer tells you which resolver answered, on the SERVER line, so you know whose view of DNS you are seeing, along with how long the query took.

Two extra points make the output far more useful. First, if the ANSWER SECTION shows a CNAME line above the A line, the name is an alias that points at another hostname, and dig has followed the chain to the final address for you. This is extremely common when a domain uses a CDN or when you look up a www subdomain, and it is the first visible sign that something sits between the name and the real server. Second, the TTL matters whenever you have just changed where a domain points: it is the number of seconds a resolver is allowed to cache this answer, so after a change a lookup can keep showing the old address until the TTL counts down and expires. That is why lowering a record's TTL a day before a planned move, and querying a public resolver directly afterwards, gives you a truer picture during a migration.

Why the IP You See May Not Be the Server's Real Address

This is the single most important thing to understand, and it is where a raw lookup can quietly mislead you. A DNS lookup returns whatever address the domain's DNS is configured to hand out. When a domain sits behind a CDN or reverse proxy, that address belongs to the CDN's edge network, not to the origin server where your site actually lives. Cloudflare is the most common example, shown in its dashboard as the "proxied" or orange-cloud state. This is not a mistake; it is the entire point of a proxy. It sits in front to cache content, speed up delivery and shield the origin, and to do that it publishes its own address and keeps the origin's address hidden.

On Noiz hosting this plays out simply. If your domain uses the Noiz nameservers ns1.noiz.co.za and ns2.noiz.co.za with nothing proxying in front, a lookup returns your actual Noiz server address. If you have put a CDN or proxy in front of the domain, a lookup returns the CDN's address instead, and your true Noiz origin stays out of sight even though the site is still served from Noiz. Both situations are correct; you just need to know which one you are looking at.

The confusion this causes almost always takes one of these shapes:

• Allow-listing the wrong thing. If you add the resolved address to a firewall or an allow-list expecting to reach the origin, you may have allow-listed the CDN's edge instead, and the rule will not do what you intended.
• "Is my site on the right server?" When a proxy is in front, the resolved address will not match your Noiz server's address. That looks alarming but is correct, and it is not evidence that the site is hosted somewhere else.
• Migration puzzles. After moving a site to Noiz, a lookup that still shows an unfamiliar address can mean either a cached answer whose TTL has not expired, or a proxy that was never repointed at the new origin. The two need different fixes, so it is worth telling them apart.

A few other, perfectly legitimate reasons a lookup can vary are worth knowing so they do not throw you:

• Several addresses at once. A domain may publish more than one A record, and a resolver hands them out in a rotating order (round-robin). Both addresses are valid.
• A different answer depending on where you are. Large networks use anycast or geographically aware DNS, so a lookup from South Africa and a lookup from Europe can return different addresses, and both are right for the person who asked.
• Caching. As covered under TTL, a recently changed record can still show its previous value until caches expire.

When you need to tell what you are actually looking at, check who owns the address. Running a WHOIS or IP-ownership lookup on the returned address names the organisation it belongs to: if it is a CDN edge, the owner will be that CDN (for example, a Cloudflare-owned range) rather than Noiz. Be aware that a CDN's address ranges change over time, so never hard-code them; check ownership at the moment you look. A reverse (PTR) lookup on the address and the record's TTL are further clues. If you are ever unsure what your account's real server address is, or whether a proxy sits in front of your domain, the Noiz support team can confirm it directly.

Troubleshooting

• Symptom: the lookup returns NXDOMAIN or "Non-existent domain". The name is not in DNS. Check for a typo, confirm the domain has not expired, and if you have only just registered it or changed its nameservers, allow time for the change to take effect before it resolves everywhere.
• Symptom: the resolved address does not match your Noiz server's address. Most often a CDN or proxy sits in front of the domain, as explained above, or you are seeing a cached old answer. Query a public resolver directly, for example dig @1.1.1.1 yourdomain.com or nslookup yourdomain.com 1.1.1.1, to bypass a stale local cache, then check who owns the address that comes back.
• Symptom: ping times out but you still saw an address on the first line. Many servers block ping on purpose, so timed-out replies do not mean the site is down and do not mean the lookup failed. The address ping printed is still valid; use dig, host or nslookup to confirm it rather than relying on ping replies.
• Symptom: two tools, or two people, show different addresses for the same domain. This is usually round-robin records, geographically aware DNS, or caching, and all of them can be legitimate. Compare each result against the same known public resolver to get a common reference point.
• Symptom: an AAAA (IPv6) query returns nothing. The domain simply has no IPv6 record published, which is common and not a fault. The A (IPv4) record is what browsers will use.
• Symptom: on Windows there is no dig or host command. Those are not part of Windows. Use nslookup or PowerShell's Resolve-DnsName instead, or run dig from a Windows Subsystem for Linux shell if you have one.
• Symptom: you changed where the domain points but a lookup still shows the old address. This is TTL and caching. Wait out the record's TTL, flush your machine's DNS cache (ipconfig /flushdns on Windows), and query a public resolver directly to see the new value as it becomes available.

If a lookup is not returning what you expect, or you want to confirm the real server address behind a domain hosted with Noiz, open a support ticket with the Noiz support team. Tell them the exact domain, the address you are seeing, and which tool you used to get it. On a managed plan the team can confirm your account's server address, tell you whether a proxy sits in front of your domain, and help you read a confusing result so you know exactly where your domain points.