Bulk IP & Domain Lookup

What it does

Bulk IP Lookup accepts up to 200 IPv4 addresses, IPv6 addresses or domain names, either as a clean list or buried inside raw text such as firewall logs and alert e-mails, and extracts every host with pattern matching. Domains are resolved to their first A (or AAAA) address, and each resulting IP is enriched with country, city, ISP and ASN from a geolocation database plus a PTR (reverse DNS) hostname. You can optionally fetch one extra record type (MX, NS, TXT, A, AAAA or CNAME) per domain and export the whole table as CSV.

Technical background

Bulk enrichment is the first step in almost every investigation that starts from logs. A single web server under a scanning campaign can record thousands of distinct client addresses per hour, and the useful question is rarely where one IP is but how the set is distributed across networks. This tool extracts candidates with three patterns (dotted-quad IPv4, colon-separated IPv6 and DNS hostnames), validates each one, removes duplicates unless you ask to keep them, and caps the batch at 200 hosts so results return in seconds. Lookups run with a concurrency of ten, and identical hosts are only queried once even when duplicates are preserved.

The enrichment data comes from different authorities, and knowing which one answers each column tells you how much to trust it. Address ownership originates with the five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), which publish allocations through WHOIS and RDAP (RFC 9082/9083). The ASN reflects who announces the prefix in BGP, so it is the strongest signal for attribution. Country and city are produced by commercial geolocation databases that blend registry data, operator geofeeds (RFC 8805) and latency measurements, which is why a mobile carrier address may land hundreds of kilometres from the handset.

Reverse DNS is queried live as a PTR record under in-addr.arpa for IPv4 or ip6.arpa for IPv6 (RFC 3596). A PTR such as 203-0-113-7.dyn.isp.example strongly suggests a dynamic residential customer, while names like crawl-66-249-66-1.googlebot.com identify verified crawlers, but only after a forward-confirmed check: resolve the returned name and make sure it maps back to the same IP. Anyone controlling a reverse zone can publish a misleading PTR, so treat it as a hint, not proof.

A practical incident workflow is: export the suspicious lines, paste them here, sort the CSV by ASN, and look for concentration. If 80 percent of failed logins come from two hosting ASNs, blocking or challenging those prefixes at the edge is low risk. If they spread over hundreds of residential ISPs, you are looking at a botnet or proxy network and should rely on rate limiting, MFA and credential-breach checks instead of IP blocks. Remember that addresses in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918) or 100.64.0.0/10 (RFC 6598) have no public location at all; they indicate the log was written behind a NAT, proxy or load balancer that did not preserve the original client IP.

Common errors and how to fix them

Problem Every row shows a private address such as 10.0.4.12 with no country or ASN.

Fix The application logged the load balancer or reverse proxy address. Configure the proxy to pass X-Forwarded-For or the PROXY protocol, enable real-IP handling in the web server (for example nginx set_real_ip_from plus real_ip_header), and re-export the logs.

Problem The tool rejects the batch with 'Bulk lookup supports up to 200 hosts per request'.

Fix Deduplicate first (sort | uniq), keep 'preserve duplicates' off, and split larger sets into chunks of 200. For investigations, the top talkers by count usually matter more than the long tail.

Problem A domain row says 'No A or AAAA records resolved'.

Fix The name has no address records, often because it only has MX or is a mail-only domain, or the apex lacks an A record while www has one. Select the MX or NS option to see what the domain does publish, or query the exact hostname from the log.

Problem Several rows return 'Geolocation provider rate limit reached'.

Fix The upstream database throttles rapid bursts. Wait a minute and re-run only the failed rows; the ASN and PTR columns that did resolve are still valid.

Problem Version numbers or timestamps in the pasted text appear as fake IPs, such as 1.2.3.4 from a library version.

Fix The extractor matches any valid dotted quad. Pre-filter the log to the client-IP field (awk '{print $1}' for combined log format) before pasting.

Do it from the command line

# Extract and count unique IPv4 addresses from a log
grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' access.log | sort | uniq -c | sort -rn | head -20
# Reverse DNS for every IP in a file
while read ip; do echo "$ip $(dig -x $ip +short)"; done < ips.txt
# Origin ASN for 8.8.4.4 via DNS (octets reversed)
dig +short TXT 4.4.8.8.origin.asn.cymru.com

# Extract and rank IPv4 addresses from a log (PowerShell)
Select-String -Path access.log -Pattern '(\d{1,3}\.){3}\d{1,3}' -AllMatches | ForEach-Object { $_.Matches.Value } | Group-Object | Sort-Object Count -Descending | Select-Object -First 20
# PTR lookup for a list of IPs
Get-Content ips.txt | ForEach-Object { Resolve-DnsName $_ -Type PTR -ErrorAction SilentlyContinue }

# Unique source IPs from failed SSH logins
grep 'Failed password' /var/log/auth.log | grep -oE 'from ([0-9.]+)' | awk '{print $2}' | sort | uniq -c | sort -rn
# Reverse DNS for each address
xargs -n1 dig +short -x < ips.txt
# RDAP registration data for one IP
curl -s https://rdap.arin.net/registry/ip/8.8.8.8

Frequently asked questions