--- title: "How to Find the IP Address of a Website or Domain" description: "Find the IP address a domain resolves to with ping, nslookup, dig or an online tool, read the output, and spot when a CDN or proxy hides the real server." url: "https://docs.noiz.ie/domains-dns/how-to-find-the-ip-address-of-a-website-or-domain/" section: "Domains & DNS" categories: - "Domains & DNS > DNS Records" last_reviewed: "27 July 2026" --- # 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](https://www.rfc-editor.org/rfc/rfc1035): 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](https://www.rfc-editor.org/rfc/rfc3596): defines the `AAAA` record, which is how an IPv6 address is published for a name. - [nslookup (Microsoft Learn)](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup): 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)](https://bind9.readthedocs.io/en/latest/manpages.html): 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](https://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. --- Source: https://docs.noiz.ie/domains-dns/how-to-find-the-ip-address-of-a-website-or-domain/