Investigate a Suspicious IP or Domain

Route the investigation through domain facts, IP ownership, and CIDR scope in an order that produces evidence instead of guesswork.

This workflow helps with first-pass investigation only. It does not offer phishing detection, threat-intelligence coverage, or maliciousness scoring.

Start here when
A suspicious hostname, login source, or provider range needs triage before you decide whether to escalate.
Recommended order
Start with domain registration and SSL, move to IP ownership, then use CIDR only if range analysis is actually needed.
Why this order matters
You avoid blocking too broadly and keep the investigation grounded in visible registrar, ASN, and subnet facts.
Example workflows
Scenario: suspicious domain
Review registrar, recent creation dates, nameservers, and certificate timing before you pivot to IP ownership.
1. Check a domain
2. Review registrar + nameservers
3. Inspect SSL issuer and days remaining
Scenario: suspicious source IP
Start from ASN ownership when the alert already includes a public source IP.
1. Lookup an IP
2. Compare ASN + range with the expected provider
3. Escalate with those facts
Scenario: provider-wide question
Use subnet math when someone wants to allow or block an entire range after a single-host lookup.
1. Open CIDR calculator
2. Measure host count and boundaries
3. Decide whether a narrower rule is safer
Three-step checklist

Follow these steps when you need a clear first-pass process.

  • Check a domain first when you have a hostname, URL, or login origin.
  • Lookup an IP after the domain step or immediately when the alert already starts from a public IP.
  • Open CIDR calculator only when the question expands into subnet or provider-range scope.
WHOIS vs RDAP

WHOIS remains common for domains, while structured RDAP data often powers IP ownership lookups with WHOIS fallback when needed.

  • Use domain registration data for registrar, expiration, and nameserver facts.
  • Use IP ownership data for ASN, registry, and network-range context.
Trust and limitations

These steps help you verify public-record evidence. They do not replace a deeper security review or a product with threat-intelligence data.

  • Do not imply maliciousness scoring where the tool does not provide it.
  • Do not block an entire provider range until CIDR context shows the scope you are actually affecting.