Reverse IP Lookup (PTR Records)

Reverse DNS answers the opposite question from a normal lookup: given an address, which name did its owner point back at it? The page builds the reverse name itself — a.b.c.d.in-addr.arpa for IPv4, the nibble form under ip6.arpa for IPv6 — asks for the PTR record, and shows which resolver answered, what the response code was, the CNAME chain if there was one, and the TTL. The second mode walks the addresses next to the one you typed, inside the same block, one address at a time, because hosters tend to name their machines in a visible pattern. Everything here is public, passive information: no scanning, no dictionary brute force, no WHOIS.
Ready. No query has been sent yet.
Enter an address, then run the reverse lookup.
The direction of the query. A normal lookup goes from a name to an address through A and AAAA records, and the site owner controls it. A reverse lookup goes from an address to a name through PTR records, and the network owner controls it, not the website owner. That single difference explains most of what looks strange here: a name under a hoster's pattern such as srv12.hoster.example says who runs the machine, and says nothing about which website is on it.

No PTR answer is a normal result. Nobody is obliged to create a reverse name, and most address blocks never do. An empty answer means the owner left it blank or that the answer was removed, not that the address is unused or doing something wrong. It also travels through the normal cache, so a recently added name can take a while to appear everywhere.

Why the neighbours are interesting. Address blocks are handed out in ranges, and the smallest range a customer usually holds is a /24 — 256 addresses. Hosters name those addresses in a scheme, so reading a handful of names around one address often shows the pattern and the provider behind the whole block. This page asks about the addresses nearest to yours first, inside the same /24, and never goes looking for names that are not addresses.

What it does not mean. A reverse name is not a website name: the name in the answer may belong to a router, a mail relay or a load balancer rather than to any site. One address can serve hundreds of unrelated sites, and one large site can spread over dozens of addresses, so a shared name is a hint about hosting, never proof that two things are related. Treat the neighbours as a naming pattern, not as a list of owners.

Cost, and why the neighbour list is slow. Every address in the list is a separate query against the same resolver allowance the other pages use, and the list runs one address at a time with a gap between items to stay inside what public resolvers accept. A full list therefore takes a while, and you can cancel it: the remaining addresses are dropped without leaving anything running.

What this page does not do. No dictionary brute force, no range scanning, no port probing and no registration data lookup. If an address has no reverse name and you want to know whose network it sits in, the honest next step is the IP Lookup page, which reads the network and location fields that public services do publish, and the Subnet Calculator, which shows the block boundaries of that address without sending anything anywhere.

Public sources you can read yourself. The authoritative record of who holds an address range is kept by the regional registries: the IANA IPv4 address space and IANA IPv6 unicast assignments files list which registry received each block, and each registry then publishes its own delegation records. This page deliberately does not query those files: they are a separate, heavier kind of query, and reading them by hand from the links above is the honest way to answer “whose network is this”.