{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }}

Use one public target such as 8.8.8.8 or example.com. Only the first usable line is checked.
This helper contacts a public IP-detection service only after you select it.
Automatic fallback tries Cloudflare, Google Public DNS, then Quad9.
Keep this on for mail identity, allow-listing, or address-ownership review.
{{ fcrdnsEnabled ? 'On' : 'Off' }}
Only the first usable target was checked; {{ ignoredExtraLines }} additional lines were was ignored.
Leave blank for no expected-name policy.
{{ option.help }}
{{ option.value ? 'On' : 'Off' }}
0 uses the safe automatic limit; otherwise check 1–24 resolved addresses.
IPs
0 uses the resolver default; otherwise allow 1000–15000 milliseconds per DNS query.
ms
CheckStateEvidenceOperator noteCopy
{{ row.check }}{{ row.state }}{{ row.evidence }}{{ row.note }}
IPVerdictPTR hostnamesFCrDNSExpectedScopeResponseCopy
{{ row.ip }}{{ row.verdict }}{{ row.ptrHosts }}{{ row.fcrdns }}{{ row.expected }}{{ row.scope }}{{ row.response }}
PathIPHost or answerStateEvidenceCopy
{{ row.path }}{{ row.ip }}{{ row.host }}{{ row.state }}{{ row.evidence }}
Policy checkStateEvidenceNext actionCopy
{{ row.check }}{{ row.state }}{{ row.evidence }}{{ row.action }}
IPResolverPTR answer setResponseCopy
{{ row.ip }}{{ row.resolver }}{{ row.ptrHosts }}{{ row.response }}
Reverse DNS Zone Generator Generate an IPv4 reverse DNS zone with PTR records and SOA validation plus RFC 2317 classless delegation and parent-zone CNAME guidance.
DNS Record Lookup Look up DNS records for a domain, URL or IP through Google or Cloudflare with response codes, returned TTL evidence and DNSSEC flags.
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
Nameserver Health Check Check a domain’s resolver-visible nameserver set and verify address coverage, SOA presence, and cross-resolver drift before a DNS cutover.

Most DNS lookups begin with a hostname and return an address. Reverse DNS starts with an IPv4 or IPv6 address and asks the address owner's reverse zone for a PTR record. The answer supplies a hostname that can make logs easier to read, support mail-server identity checks, and help operators recognize the system assigned to an address.

PTR record
The reverse-DNS record that maps an IP address to a hostname.
Forward-confirmed reverse DNS
A round trip in which a returned PTR hostname resolves forward to the original IP address. It is commonly shortened to FCrDNS.
Resolver view
The answer visible through one recursive DNS service, including its cache and policy at that moment.

A PTR answer is useful identity evidence, but it is not proof of ownership, reachability, or trust. Reverse zones are usually controlled by an internet service provider, cloud platform, or address-space owner rather than the customer using the address. A host can therefore be working normally while its PTR record is missing, stale, generic, or outside the customer's direct control.

Forward confirmation catches a common inconsistency. If 198.51.100.24 points to mail.example.net, the A or AAAA records for that hostname should include 198.51.100.24 when the name is meant to identify the address. A mismatch can come from an unfinished migration, a reused address, a stale forward record, a shared hostname, or a split view of DNS.

Multiple PTR names are legal to publish, but operational policy varies. Some environments accept any PTR hostname that round-trips; others require every returned name to match, exactly one PTR record, or a name under an approved suffix. Resolver disagreement is also a clue rather than a final diagnosis because caches can retain different answers until their time to live (TTL) expires.

Private, loopback, link-local, carrier-grade NAT, documentation, multicast, and other special-purpose addresses need different expectations from public addresses. Missing public PTR data can affect mail or allow-listing reviews. Missing private PTR data may simply mean the internal resolver or reverse zone was not queried from the correct network.

How to Use This Tool:

Use one public address or hostname from the system you are investigating. A hostname fans out to its A and AAAA addresses before the reverse checks begin.

  1. Enter one IP address or hostname in IP or hostname. URLs and email-style targets are reduced to their host, and only the first usable pasted line is checked.
  2. Keep Forward-confirmed rDNS on when mail identity, allow-listing, or address ownership matters. Add an Expected PTR host or suffix only when the environment has a real naming rule; prefix an exact name with =.
  3. Choose a Resolver or use automatic fallback. In advanced policy, enable every-PTR matching, strict single-PTR review, hostname hygiene, or public-resolver comparison only when those checks match the operating requirement.
  4. Select Check reverse DNS. Read Action brief for the overall judgment, then use PTR ledger and Lookup paths to trace the reverse answer and each forward confirmation.

Interpreting Results:

Verdict Meaning Follow-up
ALIGNEDNo selected rule found a conflict for that IP.Keep the result as resolver-visible evidence, not proof of authoritative configuration.
REVIEWA local policy, hostname-quality, expected-name, scope, or resolver-agreement check needs attention.Read the exact row before changing DNS.
FAILA public address has no PTR data, or the enabled FCrDNS rule has no acceptable round trip.Verify the authoritative reverse zone and matching A or AAAA data.

The alignment percentage is the share of checked IPs with severity zero. One failed address makes the overall state Reverse DNS fixes needed; otherwise any review row makes it Reverse DNS review needed. A high percentage can therefore coexist with a consequential failure on one address.

When resolver comparison is enabled, different PTR answer sets produce review evidence. Wait through the relevant TTL and query the authoritative reverse zone before concluding that the zone itself is wrong.

Technical Details:

Reverse lookup owner names depend on the address family. IPv4 uses the octets in reverse order under in-addr.arpa. IPv6 expands the address to 32 hexadecimal nibbles, reverses the nibbles, separates them with dots, and appends ip6.arpa. PTR targets are normalized without a trailing dot before comparison.

Lookup Core:

Stage Question Evidence retained
Input resolutionWhich A and AAAA addresses belong to a hostname?Up to 24 unique resolved addresses.
Reverse lookupWhich PTR hostnames are returned for each reverse owner name?PTR names, minimum returned TTL, resolver, and elapsed time.
Forward confirmationDoes each PTR hostname's A or AAAA set contain the original IP?Returned addresses and a per-host round-trip result.
Optional naming checkDoes a PTR hostname match the exact expected name or suffix?Match counts, hostname warnings, and optional CNAME evidence.
Optional resolver comparisonDo Cloudflare, Google Public DNS, and Quad9 return the same PTR set?Each resolver's answer set, response code, and duration.

Rule Core:

The model assigns severity 0 for aligned, 2 for review, and 3 for fail. The following rules are applied per IP, and the highest applicable severity wins.

Condition Severity
No PTR answer for a public IPFail
No PTR answer for a non-public IPReview
FCrDNS enabled and no PTR hostname resolves to the original IPFail
Every-PTR matching enabled and fewer round trips than PTR answersFail
Strict single PTR enabled and the PTR count is not exactly oneReview unless already failed
Expected-name rule supplied and no PTR hostname matches itReview unless already failed
Hostname hygiene enabled and a PTR target has CNAME evidence, invalid hostname syntax, or an all-numeric final labelReview unless already failed
Resolver comparison enabled and one PTR set differs from the primary viewReview unless already failed

Formula Core:

Alignment is a presentation summary of the rule results. It is rounded to one decimal place after division.

Alignment = Aligned IPsChecked IPs × 100 %

An expected value beginning with = requires exact hostname equality after case folding and trailing-dot removal. Without =, the rule accepts either the exact hostname or a name beneath that suffix. Automatic resolver fallback tries Cloudflare, then Google Public DNS, then Quad9 only when a transport request fails. A successful DNS response with no PTR answer is retained as an answer-state result rather than triggering fallback. Each DNS query uses a 6,500 ms default timeout unless a value from 1,000 to 15,000 ms is supplied.

Privacy and Accuracy Notes:

Live checks send hostnames, addresses encoded as reverse owner names, and optional forward or CNAME questions to the selected public DNS-over-HTTPS resolver. Use current IP also asks a public address-detection service for the browser's current public IP. These network requests can reveal which systems are being investigated.

  • Results show recursive-resolver evidence, not a direct authoritative query.
  • Private and split-horizon PTR records may be invisible from public resolvers.
  • FCrDNS consistency does not authenticate a host, prove control of the address, or guarantee mail acceptance.

Worked Examples:

Mail address with a complete round trip

An address returns mail.example.net, and that hostname resolves back to the original address. With FCrDNS enabled and no stricter naming policy, the row is ALIGNED. The result supports a consistency check but still needs mail authentication and recipient-log evidence.

Stale PTR after a migration

A public IP still returns an old hostname whose A record points elsewhere. The reverse answer exists, but the round trip count is zero, so the enabled FCrDNS rule fails. Correct the PTR target or restore matching forward data through the address owner, then recheck after the old TTL has expired.

References: