See exactly which IPv4 address (or addresses) a domain resolves to, right now, from a live DNS query — including TTL, round-robin detection, and the raw resolver response.
An A record is the DNS record type that ties a hostname to an IPv4 address — nothing more abstract than that. When you type a domain into a browser, one of the first things that has to happen before anything else is a lookup that turns that name into a number a network can actually route packets to. This tool runs that exact lookup live, against a public DNS-over-HTTPS resolver, and shows you every address currently published, not a cached or assumed answer.
It's a narrower, more focused tool than a general-purpose DNS lookup — it doesn't try to show every record type a domain has. If you need the full picture (MX, TXT, NS, CNAME, SOA all at once), our broader DNS Lookup tool covers that. This one exists because A records specifically come up constantly on their own — verifying a deployment, confirming a CDN cutover, checking whether a DNS change has actually taken effect — and deserve a tool that answers just that question, fast.
⭐
ToolsNovaHub Pro Tip
If a domain returns multiple A records, don't assume the first one listed is "the real server." Order isn't guaranteed to be meaningful — some resolvers rotate it — so treat every returned address as equally live unless you have other evidence.
⚠️
Common Beginner Mistake
Assuming a DNS change "didn't work" because a lookup still shows the old IP minutes after updating a record. What you're seeing is a cached answer honoring the previous TTL — it will update once that cache entry expires, not before.
🔄 How This Lookup Works Under the Hood
This tool queries a public DNS-over-HTTPS endpoint directly from your browser and requests only the A record type for the hostname you enter. That's a recursive query — the resolver you're querying does the work of walking from the root zone down through the TLD to the domain's authoritative nameservers on your behalf, then hands back a final answer, cached for whatever TTL the authoritative server specified. What you see here reflects that resolver's current view, which in nearly all cases matches what the rest of the internet using the same resolver network will also see.
Field
What It Tells You
IPv4 Address
The exact address traffic to this hostname will be routed to
TTL
How long resolvers will cache this answer before re-querying, in seconds
Record count
Whether the domain uses a single server or multiple (round-robin / geo-distributed)
📊 A Records vs Other Record Types
It's worth being precise about what an A record does and doesn't do, since it's easy to conflate with related record types that solve adjacent but different problems.
Record Type
Points To
Typical Use
A
An IPv4 address, directly
Resolving a hostname to an IPv4 server
AAAA
An IPv6 address, directly
Resolving a hostname to an IPv6 server
CNAME
Another hostname (an alias)
Pointing a subdomain at a service without hardcoding an IP
MX
A mail server hostname
Routing inbound email, never an IP directly
NS
Authoritative nameserver hostnames
Delegating a zone's DNS authority
🌐 Real-World Situations Where This Tool Helps
🚀
Confirming a Deployment or Migration
After pointing a domain at a new server or host, use A Record Lookup to confirm the change resolved correctly before assuming a downstream issue (like a broken app) is the real problem.
🌐
CDN and Load Balancer Verification
Many CDNs and load balancers return multiple A records that rotate or vary by region. Checking here confirms your edge configuration is actually publishing the addresses you expect.
⏳
TTL Auditing Before a Cutover
Before a planned server migration, check the current TTL here. A high TTL left unchanged means your cutover will take longer to reach every visitor than you might expect.
🔍
Diagnosing "Site Down for Some People"
If a site is reachable for some visitors and not others, comparing A record results here against what affected users' own resolvers return can reveal a resolver-caching mismatch rather than a real outage.
🔐
Pre-Deployment Security Review
Confirming exactly which IP a production domain resolves to is a basic first step before firewall rule changes, WAF onboarding, or any security control that needs to know the true origin address.
📋
Documentation and Change Records
Copy the raw DNS response here into change tickets or runbooks — a timestamped record of exactly what a domain resolved to at a given moment is genuinely useful during incident review.
🔗 More Ways to Investigate DNS
For the complete record picture beyond just A records, use DNS Lookup. To check whether a DNS change has propagated across resolvers worldwide, use DNS Propagation Checker. To go the other direction — from IP back to hostname — try Reverse DNS Lookup. And to look up ownership and registration details for the domain itself, use WHOIS Lookup.
ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.
An A record is the DNS record type that maps a hostname directly to an IPv4 address — the record a browser or app ultimately needs to actually connect to a server.
Why does a domain sometimes return multiple A records? +
Usually deliberate — round-robin load balancing across several servers, or geo-distributed endpoints. Clients typically try one and fall back to another on failure.
Why does my A record lookup show an old IP after I changed DNS? +
You're likely seeing a cached answer that hasn't expired yet — resolvers cache A records for the duration of the TTL. It updates automatically once that cache entry expires.
What's the difference between an A record and a CNAME? +
An A record points directly to an IPv4 address. A CNAME points to another hostname instead, which then has to be resolved further — useful when the target's IP might change.
Can a domain have both an A record and a CNAME for the same name? +
No — DNS specification disallows a CNAME coexisting with any other record type for the same exact name, including A. A name must pick one or the other.
Does this tool show IPv6 addresses too? +
No — this tool is scoped specifically to A records (IPv4). For IPv6 (AAAA records), use our IPv6 Lookup tool.
What does TTL mean in the results? +
TTL (Time to Live) is how many seconds DNS resolvers will cache this answer before querying again. A TTL of 3600 means roughly one hour of caching.
Is this a live DNS query or a cached database lookup? +
Live — every lookup queries a public DNS resolver directly at the moment you click "Lookup," reflecting the current published record, not a stored snapshot.
Why would an A record lookup return no results? +
Either the domain doesn't exist, or it exists but has no A record configured — some domains only publish AAAA (IPv6) or route exclusively through other mechanisms.
Is A Record Lookup free to use? +
Yes — completely free, no signup, unlimited queries. Results come from a public DNS resolver and appear instantly.
Can I use this to check a subdomain's A record? +
Yes — enter the full subdomain, like blog.example.com, and the tool queries that exact name rather than the root domain.
Why do results sometimes differ from what my own computer resolves? +
Your device's local resolver may have a different cached copy with a different remaining TTL than the public resolver this tool queries directly.
Does a low TTL slow down my website? +
No — TTL only affects how often resolvers re-query DNS, not how fast a page loads once resolved. A low TTL means more frequent DNS lookups, not slower connections.
Can A Record Lookup tell me who hosts a website? +
Indirectly — the returned IP address can be cross-referenced with an IP lookup tool to identify the hosting provider or ASN, though it isn't shown directly on this page.
What should I check if a lookup returns an unexpected IP? +
Verify the record directly in your DNS provider's dashboard, confirm there's no stale record left from a migration, and check whether a CDN or proxy is intentionally serving a different address than your origin server.
🎓
Expert Tip
When comparing A record results across two different resolvers to diagnose a propagation issue, always note the TTL from each — a mismatch in remaining cache time explains most apparent inconsistencies.