A Record Lookup – IPv4 DNS Record Checker

Every time a browser, API client, or monitoring probe connects to your site by name, DNS A records translate that hostname into an IPv4 address. Without correct A records, traffic never reaches your server — even when the server itself is healthy.

An A record lookup shows exactly which IPv4 addresses are published right now, including TTL values that control how quickly changes propagate across the internet.

Whether you are a developer validating a deployment, an IT admin updating firewall rules, or a site owner confirming a hosting move, this tool on VSPIC gives you authoritative A answers in seconds.

A DNS A record — short for Address — stores one or more IPv4 addresses for a hostname. It is defined in the DNS protocol and is the default way clients resolve website names to routable IPv4 targets.

Each A record answer includes the queried name (host), the IPv4 value (such as 93.184.216.34), and a TTL that tells resolvers how long they may reuse the answer without asking again.

A records apply to hostnames, not bare IP addresses. To find names for an IP, use reverse DNS (PTR) instead.

When a resolver receives a query for type A, it walks the DNS hierarchy from root to TLD to the domain's authoritative nameservers. The authoritative zone returns A resource records for the matching name.

If multiple A records exist, resolvers may return all of them. Clients often try the first answer or spread connections across the set for simple load distribution.

A records do not follow CNAME chains by themselves — if a name is a CNAME, the resolver first finds the canonical target, then queries A records on that target.

Resolution begins with a stub resolver on the client or a recursive resolver on the network. The recursive server caches prior answers and forwards misses to authoritative nameservers listed in NS records.

For apex domains like example.com, the A record lives in the zone file at the authoritative DNS host. For subdomains like api.example.com, the same zone or a delegated child zone publishes the A answer.

Caching layers — browser, OS, ISP resolver, and CDN — mean different observers can briefly see different A values during a migration until old TTLs expire.

• Type the hostname without http:// or paths — use example.com or www.example.com.
• Click Lookup A Records and wait for the results table.
• Read the Host column for the exact DNS name that was answered.
• Read the Value column for each IPv4 address currently published.
• Note TTL in seconds to estimate how long caches may hold old values.
• Copy any IP with the copy button for tickets, allowlists, or documentation.

• Focused IPv4 answers without scrolling through unrelated record types
• Host, value, and TTL columns aligned with how DNS admins think
• Copy-friendly output for change requests and runbooks
• No account, plugin, or command-line tool required
• Works on mobile for quick checks from any network
• Pairs with AAAA, CNAME, and full DNS Lookup on the same site

• Pointing A to a decommissioned server after a migration
• Leaving www and apex on different IPs without redirects
• TTL left at 86400 during a planned cutover, slowing rollback
• Publishing private RFC1918 addresses in public zones by mistake
• Conflicting A and CNAME on the same name (invalid in standard zones)
• Forgetting to update A records when changing hosting providers

• Lower TTL several hours before a planned IP change, then restore afterward
• Document both apex and www A targets in your runbook
• After edits, verify with this lookup from an external network
• Pair A checks with SSL certificate and HTTP header verification
• Use monitoring that alerts when live A records drift from expected values
• Keep a rollback IP noted until TTL proves the new answer everywhere

• AAAA Record Lookup
• CNAME Lookup
• DNS Lookup
• Hostname Lookup
• Website IP Checker
• NS Lookup

• RFC 1035 — Domain Names (A records)
• RFC 1034 — Domain Names — Concepts

DNS answers may be cached or vary by resolver location and time. Results are for operational troubleshooting and planning, not legal proof of ownership or routing.