Hostname to IP

About this tool

Hostname to IP performs a real-time DNS A-record lookup - it resolves a domain name to the IPv4 address (or addresses) that DNS returns at this moment. This is useful for confirming where traffic actually goes, checking whether a DNS change has propagated, and verifying endpoint targets before or after infrastructure migrations. The lookup uses Google's public DNS JSON API so results reflect global DNS, not just your local resolver cache.

Real example

Input: example.com

The tool queries the Google DNS API for A records on example.com. The response includes one or more IPv4 addresses - in this case 93.184.216.34 (IANA's example domain).

For a load-balanced service like google.com, the response returns several IPs that rotate on each query. This is expected and is part of DNS-based load balancing - you will see different addresses depending on when and from where the query is made.

Common use cases

• DNS propagation check: After updating an A record, use this tool to confirm the new IP is returned. Keep in mind TTL caching - the old address may still be returned for up to the TTL duration after the change.
• Infrastructure migration validation: Before cutting traffic to a new server, confirm the domain resolves to the new IP. After the migration, verify the old IP no longer appears in results.
• Firewall and allowlist configuration: When you need to allowlist a third-party SaaS service by IP, look up its hostname here first. For CDN-hosted services, you may need to allowlist a range - use IP Lookup to find the ASN for the returned addresses.
• Security investigation: When investigating a suspicious domain, resolving its hostname gives you the hosting IP. Combine with WHOIS Lookup and IP Lookup to identify the registrar and hosting provider.

How it works

The tool sends a request to https://dns.google/resolvename=<hostname>&type=A. Google's DNS-over-HTTPS API returns A-record results in JSON format. Only records of type 1 (IPv4 A records) are extracted and displayed. The lookup reflects what Google's public resolver (8.8.8.8) sees - not your local resolver or ISP cache.

Common mistakes

• Expecting a single IP for load-balanced services: High-traffic sites (AWS, Google, Cloudflare) return multiple IPs that change per query. You cannot reliably allowlist these services by IP - use hostname-based rules or the provider's published IP ranges instead.
• Confusing cached results with propagation: If a lookup still returns the old IP after a DNS change, it likely means Google's resolver still has the old record cached. Wait for the TTL to expire before concluding propagation is complete.
• Entering bare hostnames without a TLD: myserver is a valid hostname only inside a private DNS zone. External DNS will not resolve it. Use the fully qualified domain name (FQDN): myserver.example.com.

FAQ

Does this return IPv6 addresses
No. This tool queries only IPv4 A records. AAAA records (IPv6) are not currently included in the output.

Why do I get different IPs on different lookups
DNS-based load balancing is intentional for large services. Each query returns a different member of a pool. This is normal and expected behavior.

Can I look up internal/private hostnames
No. The lookup goes through Google's public resolver, which does not have access to private DNS zones or split-horizon configurations. Use your local nslookup or dig for internal hostnames.

What is the TTL for these results
The Google DNS API returns TTL values in the JSON response, but this tool displays only the IP addresses. For TTL details, use dig example.com A from your terminal.

How DNS resolution works

When you type a hostname into a browser or make an API call, your machine needs an IP address before it can open a TCP connection. The DNS (Domain Name System) resolution process turns that hostname into one or more IP addresses through a chain of lookups.

Your operating system first checks its local DNS cache. If the answer is cached and the TTL (Time to Live) has not expired, the cached IP is used directly — no network query. If not cached, the OS sends a query to its configured recursive resolver (typically your ISP's DNS server, or a public resolver like 8.8.8.8 or 1.1.1.1).

The recursive resolver walks the DNS hierarchy: it queries a root nameserver for the TLD (e.g., .com), gets referred to the authoritative nameserver for that TLD, then queries that nameserver for the specific domain, and finally reaches the domain's own authoritative nameserver which returns the A record. The recursive resolver caches the result according to the TTL and returns the IP to your machine.

This tool sends your hostname query to Google's DNS-over-HTTPS API (dns.google), which performs the full recursive resolution and returns structured JSON. The result reflects what the public internet's DNS infrastructure currently resolves — useful for verifying propagation, debugging routing, or checking which IPs a service is currently advertising.

DNS in incident response and debugging

Propagation verification: After a DNS change (new A record, IP change after a migration), propagation across the global resolver network takes time determined by the old record's TTL. This tool queries Google's resolver — one of the most widely used — which gives you a representative view of what most users currently resolve. If this tool returns the new IP but users report seeing the old one, they may be hitting a resolver that cached the old value longer.

Load balancer and CDN detection: Services behind a load balancer or CDN often return multiple A records with short TTLs. If this tool returns three or four different IPs for the same hostname across multiple lookups, the service is using DNS-based load balancing. Each IP is a different server or edge node. For investigation purposes, each IP may need to be analyzed separately.

Unexpected resolution: If a hostname resolves to an IP you do not recognize, cross-reference with IP Lookup to see the ASN and organization. An internal service resolving to an external IP can indicate a misconfigured split-horizon DNS or a hijacked domain. A domain resolving to a hosting provider you do not use can indicate domain shadowing or a compromised DNS zone.

For deeper domain investigation after resolution, use WHOIS Lookup. To geolocate and check the ASN of the resolved IP, use IP Lookup. To verify whether the IP falls in an expected subnet, use CIDR IP Converter.