Network Investigation Lab

Check Whether an IP Address Is Public, Private, or Reserved

Paste a domain, an IPv4 or IPv6 address, a CIDR range, or a full URL, and this tool normalises it and tells you which address space it belongs to — public, RFC 1918 private, loopback, link-local, multicast, or a documentation and benchmarking range. That single answer settles a surprising number of arguments, because half of “why does this lookup return nothing?” turns out to be an address that no external service can see in the first place.

It also does the thing no lookup tool does: compares two DNS snapshots you captured at different times and shows exactly which records were added, removed, or had only their TTL changed. No query is sent, no port is touched, and no scan of any kind is performed — every external lookup stays an explicit, separate decision you make afterwards.

Address Scope Classification

Scope is decided from the address itself, with no lookup. The ranges recognised:

The documentation row is the one that catches people out. 192.0.2.x, 198.51.100.x, 203.0.113.x, and 2001:db8:: are reserved by RFC for writing examples, and 198.18.0.0/15 is reserved for benchmarking. They look completely ordinary. When one appears in a firewall rule, a monitoring config, or a ticket, it almost always means someone copied an example out of documentation and never substituted the real value.

A known limit worth stating: carrier-grade NAT space, 100.64.0.0/10, is not in the classifier and reports as public. If you are troubleshooting a residential or mobile connection and see a 100.64–127.x.x address, that is CGNAT — the subscriber is behind the carrier’s NAT and is not directly reachable, whatever this tool says about it.

When a target lands in private, loopback, or link-local scope, the tool says so explicitly: a public lookup service cannot reach it. That is the answer to most “the geolocation tool returned nothing” and “the reputation check says unknown” questions. There is nothing to look up, because the address is meaningful only inside your own network.

URL and Domain Normalisation

URLs are parsed and cleaned before anything else happens, and the tool tells you what it removed:

• Embedded credentials are stripped. A https://user:password@host/ URL has its username and password removed before the target can be saved or handed to another tool — credentials in a URL should not be travelling into a query string.
• Query strings and fragments are stripped for the same reason. Session tokens, tracking values, and password-reset parameters live there, and an investigation target does not need them.
• The port is resolved from the URL if present, otherwise defaulted from the scheme — 443 for HTTPS, 80 for HTTP.
• Cleartext HTTP is flagged as a finding.

Domains are lowercased, have any trailing dot removed, and are validated label by label: 253 characters maximum overall, each label alphanumeric with internal hyphens only, at least one dot required. A CIDR prefix is bounds-checked against its family — 0 to 32 for IPv4, 0 to 128 for IPv6 — so a /64 typed against an IPv4 address is rejected rather than silently accepted. Input is capped at 2,048 characters.

Comparing DNS Records Before and After a Change

The diff answers a question that is awkward to answer any other way: what actually changed? Capture the zone before a migration, capture it after, paste both in, and the tool separates the result into three buckets.

• Added — a name, type, and value combination present in the after snapshot only.
• Removed — present in the before snapshot only.
• TTL changed — the same name, type, and value, with a different TTL. This is broken out separately on purpose, because a TTL-only change is not a routing change but it absolutely does change how long a mistake will keep hurting you.

Records are matched on name, type, and value together, all normalised — names lowercased with the trailing dot removed, whitespace in values collapsed. So EXAMPLE.COM. and example.com compare equal, and a record that moved position in the file is not reported as a change.

The parser accepts what you already have rather than requiring a particular format. Paste dig answer sections, zone-file lines, or normalised output; comment lines beginning with ; or # are skipped. It reads name [ttl] [class] TYPE value and recognises A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV, PTR, DS, DNSKEY, and TLSA. Quoted strings are kept intact, which matters for TXT, SPF, and DKIM records. Lines it cannot make sense of are skipped rather than failing the whole paste, so a header or a stray blank line does no harm. Each snapshot is limited to 250 KiB and 5,000 lines.

The practical capture is dig example.com ANY +noall +answer before the change and again after, or an export from your DNS provider. Because the comparison is purely local, it works on snapshots from a zone you cannot query publicly — internal split-horizon DNS, a zone file from a backup, or records for a domain that has not been delegated yet.

Handing the Target to the Right Lookup

Once a target is normalised, the tool offers only the lookups that make sense for its kind, with the value already filled in. A domain offers DNS lookup, WHOIS, and the SSL checker. An IP address offers geolocation and an IP reputation check. A CIDR range offers the subnet calculator. A URL offers a redirect chain check. Packet and firewall analysis are always available.

That routing is the point of normalising first. Running a WHOIS on an IP, a geolocation on a hostname, or a reputation check on an RFC 1918 address all return something unhelpful, and each of those is a few minutes spent on a result that was never going to mean anything.

Keeping the Investigation

Saving a workspace keeps the normalised target, both DNS snapshots, the diff, the findings, and your own notes and tags. It is held in this browser’s local storage — 30-day expiry, up to 24 workspaces, 128 KiB each — and travels to the linked tools through the URL so the target does not have to be retyped. Nothing is transmitted, and clearing site data deletes it.

The saved record is a reproducibility aid: it captures what you looked at and what you concluded, in a form a colleague can reload. It is not a chain of custody and should not be presented as one.

How to Use the Investigation Lab

1. Enter the target — a domain, IPv4 or IPv6 address, CIDR range, or full URL.
2. Select Analyze locally. No query is sent and no scan is run.
3. Read the kind, normalised form, and scope. If scope is private, loopback, or link-local, stop before running any external lookup.
4. Check the findings for stripped credentials, removed query strings, cleartext HTTP, or a reserved-range address.
5. Paste DNS snapshots into Before and After to diff a change, reading the TTL-changed column separately from added and removed.
6. Follow a suggested lookup — only the ones valid for this target kind are offered, pre-filled.
7. Save the workspace to carry the target and findings into the next tool.

Frequently Asked Questions

How do I tell if an IP address is private?

For IPv4, it is private if it falls in 10.0.0.0/8, 172.16.0.0 through 172.31.255.255, or 192.168.0.0/16. The 172 range is the one people get wrong — it is only the second octet 16 through 31, so 172.15.x.x and 172.32.x.x are public. For IPv6, unique local addresses start with fc or fd. Paste the address above and the scope is stated outright.

Does this tool query DNS or scan the target?

No. Classification is computed from the address text, and the DNS comparison works on snapshots you supply. No packet is sent to the target, no resolver is queried, and no port is probed. Every external lookup is a separate link you choose to follow.

Why did my IP lookup return nothing useful?

Most often because the address is not publicly routable. Geolocation, WHOIS, and reputation services have no data for RFC 1918 private space, loopback, or link-local addresses, because those addresses mean something different on every network. Check the scope first.

What format should I paste the DNS snapshots in?

Whatever you have. dig answer sections, zone-file lines, or a provider export all work, and comment lines are ignored. The parser reads name, optional TTL, optional class, type, and value, and skips lines it cannot interpret rather than rejecting the whole paste.

Why are TTL changes shown separately from added and removed records?

Because they mean something different. An added or removed record changes where traffic goes. A TTL change only changes how long resolvers cache the answer — which is invisible until something goes wrong, at which point a long TTL is the difference between a five-minute rollback and a day of stale answers. Lowering TTLs before a migration and raising them afterwards is standard practice, and this column is how you confirm it actually happened.

An address in my config looks normal but is flagged as documentation. What does that mean?

192.0.2.x, 198.51.100.x, 203.0.113.x, and 2001:db8:: are reserved by RFC for examples, and 198.18.0.0/15 for benchmarking. Finding one in a live configuration almost always means a placeholder was copied from documentation and never replaced.

Why were my URL’s query parameters removed?

Deliberately. Query strings and fragments routinely carry session tokens, reset links, and tracking identifiers, and the normalised target gets saved and passed into other tools through URLs. The host, scheme, and port are what an investigation needs; the parameters are risk with no analytical value.

Do I need an account?

No. This and the rest of our network tools are free and need no signup. For live record queries use the DNS lookup tool; for subnet and CIDR arithmetic use the subnet calculator.