--- title: Is my domain pointing to the right IP? Check an A record with the A Record Lookup description: You moved your site to a new host or set up a custom domain on GitHub Pages, Netlify or a VPS, and the site doesn't load, or loads only sometimes. To check an A record, look up the IPv4 addresses the domain resolves to and compare them with the exact list your host gives you, no more and no fewer. Here's how to do it with the free A Record Lookup, a real GitHub Pages check, and the dig and curl commands that confirm it. canonical: https://watchfor.io/blog/how-to-check-an-a-record --- # Is my domain pointing to the right IP? Check an A record with the A Record Lookup 2026-10-04 · WatchFor Team · Guides · guides, dns, networking You moved your site to a new host or set up a custom domain on GitHub Pages, Netlify or a VPS, and the site doesn't load, or loads only sometimes. To check an A record, look up the IPv4 addresses the domain resolves to and compare them with the exact list your host gives you, no more and no fewer. Here's how to do it with the free A Record Lookup, a real GitHub Pages check, and the dig and curl commands that confirm it. To check an A record, look up the IPv4 addresses a domain resolves to and compare them with the addresses your hosting provider tells you to use. The set should match exactly: every address the host lists, and nothing else. A missing address costs you redundancy, and a leftover address from the old server sends a share of visitors to a machine that no longer serves your site, which looks like a site that works "sometimes". The free [A Record Lookup](/a-record-lookup) shows every A record a domain returns, from a real WatchFor location, in under a second. No signup. ## What this tool answers *Which IPv4 addresses does this name resolve to right now?* Reach for it after moving to a new host, when a custom domain on GitHub Pages, Netlify, Vercel or a VPS won't load, when the browser says "site can't be reached", or when only some visitors hit an old version of the site. It answers the DNS half of the question; whether the server at that address responds is a separate check. ## A real example ### Checking an A record for a GitHub Pages custom domain A common setup that goes wrong: you point an apex domain (`example.com`, no `www`) at GitHub Pages. GitHub's documentation lists four addresses for this, and the site only works reliably, with a certificate issued, when DNS publishes them correctly. We checked a well-known site hosted this way. In the [A Record Lookup](/a-record-lookup) we typed `playwright.dev`, kept the resolver on **Auto** and pressed **Run lookup**: ![The A Record Lookup for playwright.dev from Europe / Lithuania: NOERROR, 4 records in 404 ms, addresses 185.199.108.153, 185.199.109.153, 185.199.110.153 and 185.199.111.153](/blog/how-to-check-an-a-record-result.webp) The lookup returned `NOERROR` with **4 records**: | Address | In GitHub's list for apex domains? | | --- | --- | | 185.199.108.153 | Yes | | 185.199.109.153 | Yes | | 185.199.110.153 | Yes | | 185.199.111.153 | Yes | All four match [GitHub's published addresses](https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site), and there's no fifth address left over from an earlier host. The resolve time, 404 ms in red, most likely means the resolver had nothing cached and had to ask Azure DNS, where the zone is hosted; it says nothing about the records. **The answer:** `playwright.dev` points exactly where GitHub Pages expects, and a request to it is answered by `server: GitHub.com` (see the command line section). For your own domain, any address that isn't in your host's list is the one to delete, and a short list means records still to add. ## How to read the results | What you see | What it means | | --- | --- | | **Resolve time** | How long the lookup took: green under 50 ms, amber under 200 ms, red above. A cold cache is slow; it isn't a fault. | | **NOERROR** (green) | The name resolved. | | **NXDOMAIN** (amber) | No IPv4 address came back. The name may not exist, or it exists without an A record (for example, only AAAA or MX). | | **N records** | How many addresses. More than one is normal: hosts and CDNs publish several for redundancy. | | **Address** | Each IPv4 address. If the name is a CNAME, these are the addresses at the end of the alias chain. | | **Location** | Signed out, the query runs from the WatchFor location nearest you. | The tool shows addresses without TTLs; `dig` shows them. ## More ways to use it - **Right after a migration.** Confirm the new address is in place and the old one is gone. A mixed set is the classic cause of "works for me, broken for half the office". - **When a CDN or proxy is in front.** With Cloudflare's proxy on, the A records show Cloudflare's addresses, not your server's. That's expected; the origin address lives in Cloudflare's dashboard. - **Comparing `www` and the apex.** They are separate names. Look up both; one often still points at the old host. - **Before a certificate request.** Let's Encrypt and hosting platforms validate by connecting to the address in DNS. If it points elsewhere, issuance fails. - **Checking a resolver.** Pick Cloudflare, Google or a Custom IP in the [DNS Lookup](/dns-checker) to see whether one resolver still serves an old address. ## Tips and gotchas - **Stale answers last up to the old TTL.** After a change, resolvers keep the previous address until the TTL they cached runs out. Lower the TTL a day ahead of a move; the [propagation guide](/blog/how-to-check-dns-propagation) shows how to watch the switch from 20 locations. - **The apex can't be a CNAME.** Standard DNS forbids a CNAME next to the SOA and NS records at the apex, so the bare domain needs A (and AAAA) records, or your provider's ALIAS/flattening feature. - **A records are IPv4 only.** IPv6 visitors use AAAA records. `playwright.dev` publishes none, although GitHub lists four for Pages; see the [AAAA guide](/blog/how-to-check-aaaa-records). - **Round robin isn't failover.** DNS keeps handing out a dead address; some clients retry another one, others wait for a timeout. Remove the addresses of servers you shut down. - **Right address, still down?** DNS is fine; test the server with the [port checker](/port-checker) or [HTTP header checker](/http-header-checker). ## Check it from the command line too ```bash dig +noall +answer A playwright.dev @1.1.1.1 dig +short NS playwright.dev dig +noall +answer A playwright.dev @ns1-32.azure-dns.com ``` ```text playwright.dev. 3600 IN A 185.199.108.153 playwright.dev. 3600 IN A 185.199.109.153 playwright.dev. 3600 IN A 185.199.110.153 playwright.dev. 3600 IN A 185.199.111.153 ns3-32.azure-dns.org. ns2-32.azure-dns.net. ns4-32.azure-dns.info. ns1-32.azure-dns.com. playwright.dev. 3600 IN A 185.199.108.153 playwright.dev. 3600 IN A 185.199.109.153 playwright.dev. 3600 IN A 185.199.110.153 playwright.dev. 3600 IN A 185.199.111.153 ``` The authoritative Azure server and Cloudflare's resolver agree, with a TTL of 3,600 seconds: a change would reach every resolver within an hour. Then confirm the address really serves the site: ```bash curl -sI https://playwright.dev | grep -iE "^HTTP|^server" ``` ```text HTTP/2 200 server: GitHub.com ``` ## Keep watching it An A record that changes without anyone planning it means a misconfigured deploy, an expired domain or a hijack. A [DNS monitor](/dns-monitoring) resolves the A record from several locations on a schedule, and with the **Expected DNS Records** rule (one address per line) it opens an incident when the set stops matching, with the difference in the incident's root cause. Pair it with an uptime check on the site itself. ## FAQ **How do I find out what IP address a domain points to?** Look up its A record (IPv4) and AAAA record (IPv6) with a DNS lookup tool or `dig +short example.com`. If the site is behind a CDN or proxy, you'll see the CDN's addresses rather than the origin server's. **Why does my domain still point to the old IP?** Either the record wasn't changed at the DNS provider your nameservers point to, or a resolver still caches the old answer until its TTL expires. Query the authoritative nameserver directly; the [DNS records guide](/blog/how-to-check-dns-records) shows how. **Can a domain have more than one A record?** Yes. Several A records spread traffic and add redundancy, as GitHub Pages' four addresses do. Every address must belong to a working server for that site. More on record types in [DNS record types explained](/blog/dns-record-types-explained). --- Canonical page: https://watchfor.io/blog/how-to-check-an-a-record · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt