MyIP.dogChecking…
Reverse DNS lookup
Find the PTR records published for a public IPv4 or IPv6 address. A PTR record is not a list of every website on that server.
Find the PTR records published for a public IPv4 or IPv6 address. A PTR record is not a list of every website on that server.
Checking…
A reverse DNS lookup starts with an IP address and asks for the PTR records published for it. Enter a public IPv4 or IPv6 address, then run the query. The reverse DNS lookup constructs the corresponding reverse name and sends a PTR question to Google Public DNS. The reverse DNS lookup result includes the resolver, observation time, response code, returned records, and their remaining TTLs. It does not contact every website that might share the address.
Use the address alone. Do not include http, a port, a slash prefix, or an IPv6 interface suffix. A reverse DNS lookup of 8.8.8.8 is a different question from a forward query for dns.google. If you already have a domain and want its published A or AAAA records, use DNS lookup. Forward and reverse records are maintained separately, even when an operator intentionally makes them consistent.
The example button fills a public address so you can inspect the input before sending it. The reverse DNS lookup accepts both address families and normalizes their notation. Private, loopback, link-local, shared, and documentation addresses are not submitted as public subscriber lookups here. An internal network can maintain its own reverse zone, but querying a remote public resolver cannot expose that private zone's complete configuration.
For IPv4, the reverse name places the address's octets in reverse order under in-addr.arpa. For IPv6, each hexadecimal digit is reversed under ip6.arpa. The tool performs that transformation for you, including expansion of compressed IPv6 groups. A reverse DNS lookup therefore asks a carefully constructed DNS question, not an open-ended search for text containing the address.
A PTR answer contains a domain name selected by the party controlling the reverse DNS delegation. It may describe a server, a customer circuit, a generic pool, or an operator's naming convention. Those names can be informative, but they are not verified descriptions of the person using the address. Treat a reverse DNS lookup hostname as operator-published DNS data with a time and source, rather than a personal identity record.
A reverse DNS lookup can return no answer for a perfectly active public address. Some operators do not publish PTR records for certain ranges, and a record may be absent during provisioning. Read the response code as well as the empty table. NOERROR without a PTR answer differs from NXDOMAIN, and both differ from a resolver failure such as SERVFAIL. An empty answer is not a port scan or a reachability test.
If a reverse DNS lookup fails, verify the exact address and try again after a reasonable delay. Repeated rapid requests to the same resolver are unlikely to reveal much while cached information remains valid. If you control the address, check the provider responsible for its reverse delegation. Creating a forward record in an unrelated DNS zone does not automatically create a corresponding PTR record.
The TTL shows how long the returned record can remain in a cache, subject to resolver policy. A cached TTL usually differs from the original configured TTL. When comparing reverse DNS lookup results, keep the hostname, resolver, and time together. A falling TTL is not necessarily a record change. A different hostname can reflect a changed record, different resolver state, or another difference worth checking with the authoritative source.
The protocol can return multiple records, and aliases may appear along the resolution path. A reverse DNS lookup should display those records without arbitrarily selecting a single value and calling it “the owner.” If a service expects a particular PTR configuration, consult its requirements. Mail delivery policies, for example, may care about relationships between reverse names, forward addresses, and the identity presented by the sending mail server.
A reverse DNS lookup is not a reverse IP website search. Shared hosting can serve many domains from one address, while its PTR record names only a generic host or another operator-chosen value. The returned record does not enumerate virtual hosts, TLS names, customers, or every domain with an A record pointing there. Products that claim to find hosted websites typically rely on separate historical or observational datasets.
A reverse DNS lookup is also not geolocation. An operator might put a city abbreviation in a hostname, but naming conventions can be outdated, ambiguous, or unrelated to the physical endpoint. A reverse DNS lookup cannot turn that abbreviation into a reliable map coordinate. If location is important, use an appropriate geolocation source and keep its estimate separate from any naming inference.
Use IP lookup or IP WHOIS lookup for registered network information. The responsible regional registry maintains a different kind of record from a DNS PTR answer. A reverse DNS lookup can be useful alongside registration, but a matching organization name is supporting context rather than proof of a particular user's actions. Networks can lease space, delegate reverse zones, and change customer assignments.
The query travels through our server to a named resolver. It does not observe which resolver your browser normally uses for unrelated names. A reverse DNS lookup may help describe an already identified resolver address, but it does not discover that resolver by itself. A real DNS leak test needs session-specific queries and authoritative observation. Do not read this tool's “Google Public DNS” source label as a claim about your device's DNS settings.
Usually the provider or organization controlling reverse delegation for the address can change it or give you a management interface. Your domain registrar may not be that organization. If a reverse DNS lookup shows an unwanted value, identify the relevant hosting or internet provider and ask about its PTR process. Be prepared to prove control of the address and any target hostname the provider requires.
No. Consistency can be operationally useful, but an attacker can also control consistent records for infrastructure they operate. A reverse DNS lookup is one network signal. It does not validate website content, authenticate a person, or replace application security. Avoid allowing sensitive access solely because a returned hostname appears to contain the name of a trusted company.
Yes. The tool expands the IPv6 address and reverses its individual hexadecimal digits to form the ip6.arpa name. You can enter compressed notation; you do not need to create the long reverse name yourself. A reverse DNS lookup for one IPv6 address still asks about that single address. It does not enumerate every address or every device inside the much larger assigned prefix.
Providers often generate names from an address, pool, or service category. A generic hostname may be entirely normal for a dynamic consumer connection. The reverse DNS lookup reports what was published, not what a user might prefer to be called. If you need the public address currently used by your own browser, the homepage supplies that observation without relying on a hostname convention.
Include the queried address, PTR answers, response code, resolver, and time. State the operational question you are trying to answer, such as a mail server's reverse configuration. Do not claim the hostname identifies a person or every website on the address. A reverse DNS lookup report is most useful when the recipient can reproduce the exact query and understand what the result does and does not establish.
The core DNS record format is described in RFC 1035, and IPv6 DNS representation in RFC 3596. The resolver response format comes from Google Public DNS documentation. These sources define how a reverse DNS lookup works; they do not guarantee that any particular operator publishes a PTR record.
For a comparison with hosted-domain datasets, read reverse DNS vs reverse IP. The reverse DNS guide explains forward confirmation, dated domain associations and why a shared CDN address does not establish common website ownership.