{{ summaryHeading }}
{{ alignmentFigure }}
{{ summaryLine }}
{{ overallVerdict.label }} {{ targetSummaryBadge }} {{ rows.length }} IP{{ rows.length === 1 ? '' : 's' }} {{ publicIssueCount }} public issue{{ publicIssueCount === 1 ? '' : 's' }} {{ expectedMismatchCount }} expected-host mismatch{{ expectedMismatchCount === 1 ? '' : 'es' }} {{ canonicalIssueCount }} alias/hostname warning{{ canonicalIssueCount === 1 ? '' : 's' }} {{ resolverDriftBadge }} {{ resolverSummaryBadge }}
Last run: {{ lastRunLocal }}
Examples: 203.0.113.10, 2001:db8::10, mail.example.com, or postmaster@mail.example.com.
Auto tries Cloudflare, Google, then Quad9; fixed choices keep reruns comparable.
Enter mail.example.com, example.com for suffix, or =mail.example.com for exact only.
Enable for mail reputation, allow-listing, or identity evidence.
{{ fcrdnsBool ? 'On' : 'Off' }}
Use when a multi-PTR address cannot contain any stale or weak name.
{{ require_all_ptr_matchBool ? 'On' : 'Off' }}
Enable for single-name reverse zones or mail relay audits.
{{ strict_ptrBool ? 'On' : 'Off' }}
Use for RFC-style PTR hygiene before treating the name as evidence.
{{ enforce_canonical_ptrBool ? 'On' : 'Off' }}
Adds a Resolver Drift tab when public recursive views disagree.
{{ compare_resolversBool ? 'On' : 'Off' }}
Use 0 for no cap, or a whole-number ceiling for expanded host checks.
IPs
Choose 1 to 16 parallel checks; lower it for cautious public-resolver runs.
workers
Use 0 for no extra timeout, or milliseconds in 100 ms steps.
ms
Category Field Value Detail Copy
{{ row.category }} {{ row.field }} {{ row.value }} {{ row.value }} {{ row.detail }}
# IP Verdict PTR evidence FCrDNS Expected Scope Reason Notes Copy
{{ idx + 1 }}
{{ row.ip }}
{{ row.reverseName }}
 {{ row.status }}
{{ row.ptrCount }} PTR{{ row.ptrCount === 1 ? '' : 's' }}
{{ row.ptrDisplay }}
{{ formatTtl(row.ptrTtl) }} TTL · {{ row.reverseQueryMs }} ms
{{ fcrdnsLabel(row.fcrdns) }} {{ row.expectedLabel }} {{ row.scopeLabel }} {{ row.primaryReasonLabel }} {{ row.note }}
Path IP Host / answer Status Evidence Note Copy
{{ row.path }} {{ row.ip }} {{ row.host }} {{ row.status }} {{ row.evidence }} {{ row.note }}
# IP Consensus Cloudflare Google Quad9 Notes Copy
{{ idx + 1 }}
{{ row.ip }}
{{ row.reverseName }}
 {{ row.consensus }} {{ row.cloudflareDisplay }} {{ row.googleDisplay }} {{ row.quad9Display }} {{ row.note }}
# Check Status Notes Copy
{{ idx + 1 }} {{ c.label }} {{ c.status }} {{ c.note || '-' }}
No PTR health mix data is available for this run. 

  




        

    

                

                

                    

                        

                            Tags: DNS, Diagnostics, Networking, Security
                        

                        

                            
                            
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                    

                

                

                    

                                                                                

                                
                                    
                                        Reverse DNS Zone Generator
                                                                                    Generate reverse DNS zone text for an IPv4 CIDR block with PTR rows, SOA checks, RFC2317 parent records, and review-ready JSON.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        iptables Rule Generator
                                                                                    Build iptables or ip6tables commands with CIDR, port, chain, backend, persistence, and production-review checks before firewall changes.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        MX Record Lookup
                                                                                    Look up a domain's MX records, compare public resolver answers, and flag Null MX conflicts, unresolved hosts, CNAME targets, and mail-policy clues.
                                                                            
                                    
                                
                            

                                                                                

                                
                                    
                                        DNS Record Lookup
                                                                                    Look up DNS records for a domain, host, or IP with Google or Cloudflare DoH, TTL charts, DNSSEC flags, raw responses, and JSON exports.
                                                                            
                                    
                                
                            

                                            

                

            

        
                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
Reverse DNS is the part of DNS that starts with an IP address and asks which hostname, if any, has been published for it. Normal DNS usually moves from a name to an address, such as a mail host resolving to an IPv4 or IPv6 address. Reverse DNS moves the other way by querying a PTR record in a reverse lookup zone. That reversal is useful because firewall logs, mail server logs, abuse reports, and provider tickets often begin with an address rather than a friendly name.


    
Reverse names are usually controlled by the organization that owns or delegates the address block, not always by the team that controls the forward hostname. That split is why reverse DNS can lag behind a server move, point at an old service name, or be absent even when the host itself is reachable. Forward DNS and reverse DNS live in different zones, so consistency has to be checked rather than assumed.


    
PTR records show up in practical work whenever an address needs a human-readable identity. Mail operators use them as one piece of reputation and anti-abuse evidence. Hosting teams use them to make logs and tickets readable. Security responders use them to group addresses during triage, while still treating the name as a clue rather than proof of control. A cloud migration often is not finished until the new address has a reverse name that matches the service name users and operators expect.


    

      
PTR record

      
The DNS answer that maps a reverse lookup name back to a hostname.

      
Reverse zone

      
The DNS namespace delegated for address-to-name lookups, using in-addr.arpa for IPv4 and ip6.arpa for IPv6.

      
FCrDNS

      
Forward-confirmed reverse DNS, where the PTR hostname also resolves forward to the original IP address.

    


    

      Flow from IP address to reverse lookup name, PTR hostname, and forward address confirmation.
    


    
The most common mistake is treating a PTR answer as proof of ownership or trust. Reverse DNS is only DNS evidence. It can be absent, stale, delegated to a provider the customer does not directly control, or set to a name that no longer points forward to the same address. A useful reverse DNS review checks several facts together: whether the PTR exists, whether the name is expected, whether the hostname is safe to use as an identity clue, whether public resolvers agree, and whether the forward address records still include the original IP.


    
Address scope matters before judging the result. Public server addresses are often expected to have meaningful reverse DNS, especially for mail. Private, loopback, link-local, documentation, benchmark, carrier-grade NAT, multicast, reserved, and IPv6 unique-local ranges have different expectations because their names may be meaningful only inside a private DNS environment. A missing public PTR on those ranges is usually context, not a public reverse-zone failure.


    
Timing matters after any DNS change. A provider can publish the correct PTR while public recursive resolvers still show older cached answers. Comparing resolver views can reveal that drift, but the durable fix is still in the authoritative reverse zone controlled by the IP block owner or its delegated DNS provider.

  






  

    
How to Use This Tool:

    
Use the checker to turn one address or host reference into per-IP reverse DNS evidence, then apply only the policy checks that match the job you are reviewing.


    
    
      
  1. Enter an IPv4 address, IPv6 address, hostname, URL, or email-style value in IP or hostname. The Use my IP button fills in your current public address and runs the check.
    2. 
      
  2. Leave Resolver on Auto for a general public view, or choose Cloudflare, Google Public DNS, or Quad9 when you need one repeatable resolver for a ticket or rerun.
    3. 
      
  3. Add Expected PTR host or suffix only when the reverse name must match a known hostname or domain. Use a leading = for an exact hostname match.
    4. 
      
  4. Keep Forward-confirmed rDNS enabled when mail identity, allow-listing, or address ownership evidence matters. Enable Require every PTR host to round-trip when all returned PTR names must resolve back to the original IP.
    5. 
      
  5. Use Strict single PTR when policy expects exactly one reverse name. Keep Warn when PTR target is an alias enabled when direct canonical host evidence matters.
    6. 
      
  6. Enable Compare reverse answers across resolvers after recent DNS changes or when users report different names from different networks.
    7. 
      
  7. Review Action Brief first, then open PTR Result Ledger, Lookup Paths, Policy Checks, Resolver Drift, PTR Health Mix, or JSON for the evidence you need to copy, download, or attach to a ticket.
    8. 
    


    
For hostname inputs with many A or AAAA answers, Max IPs controls how many addresses are checked. Lower Concurrency or increase Timeout if public resolver requests are slow, throttled, or inconsistent during a large run.

  






  

    
Interpreting Results:

    
Read the per-IP Verdict before drawing conclusions from the roll-up. PASS means the selected PTR, forward-confirmation, expected-host, canonical-name, and resolver checks found no issue for that address. WARN means the address still has useful evidence, but the result needs review. FAIL means a selected rule found a missing or inconsistent public reverse DNS condition.


    

      

        
        
          

            Cue
            What it means
            What to verify
          

        
        
          

            Missing public PTR
            No PTR hostname was returned for a public IP.
            Confirm the address owner or upstream provider has published the reverse record.
          

          

            Forward mismatch
            A PTR hostname exists, but its A or AAAA answers do not include the original IP.
            Check Lookup Paths and correct the forward DNS or the PTR target.
          

          

            Unexpected PTR hostname
            The PTR name does not satisfy the exact host or suffix rule you entered.
            Compare the Expected value against your naming policy before changing DNS.
          

          

            Resolver Drift
            Compared public resolvers do not show the same PTR answer set.
            Wait for TTL expiry, then verify the authoritative reverse zone.
          

          

            Scoped IP without PTR
            The address is private, loopback, link-local, documentation, unique-local, or another non-public range.
            Use private DNS expectations instead of public server expectations.
          

        
      

    


    
A clean reverse DNS result is not a certificate of service identity, mail reputation, TLS validity, or routing ownership. Treat it as a DNS consistency check. For operational changes, verify the authoritative reverse zone and repeat the lookup after caches have had time to expire.

  






  

    
Technical Details:

    
IPv4 and IPv6 use different reverse lookup name formats. An IPv4 address reverses its four octets and appends in-addr.arpa, so 11.22.33.44 becomes 44.33.22.11.in-addr.arpa. An IPv6 address expands to 32 hexadecimal nibbles, reverses those nibbles one by one, separates them with dots, and appends ip6.arpa.


    
A PTR answer is only the first half of the identity check. Forward-confirmed reverse DNS asks whether each PTR hostname has A or AAAA records that include the original IP. That catches stale names, provider mistakes, and reverse records that point at a hostname now used by another address set.


    
Lookup Core:

    

      
        
          PTRhosts
          =
          PTR
          (
          reverse-name
          (
          IP
          )
          )
        
      
      
        
          FCrDNSany
          =
          PASS iff
          
          ∃
          h
          ∈
          PTRhosts
          
          and
          
          IP
          ∈
          (
          A
          (
          h
          )
          ∪
          AAAA
          (
          h
          )
          )
        
      
      
        
          FCrDNSall
          =
          PASS iff
          
          ∀
          h
          ∈
          PTRhosts
          ,
          
          IP
          ∈
          (
          A
          (
          h
          )
          ∪
          AAAA
          (
          h
          )
          )
        
      
    


    

      

        
        
          

            Check
            Pass condition
            Warning or failure condition
          

        
        
          

            PTR presence
            At least one PTR hostname is returned for the reverse lookup name.
            Missing PTR fails public IPs and warns for scoped ranges.
          

          

            Forward-confirmed rDNS
            At least one PTR hostname resolves forward to the original IP, or every PTR hostname does when the all-host rule is enabled.
            No matching A or AAAA answer fails when forward confirmation is enabled.
          

          

            Expected hostname
            A PTR hostname equals the expected host, or equals or ends with the expected suffix.
            No PTR hostname satisfies the exact or suffix rule.
          

          

            Strict single PTR
            Exactly one PTR hostname is returned for the checked IP.
            Zero or multiple PTR names warns or fails according to the selected checks.
          

          

            Canonical hostname
            PTR targets use hostname-safe labels and avoid alias-only evidence.
            CNAME answers, empty labels, labels over 63 characters, unsupported characters, edge hyphens, or all-numeric final labels raise warnings.
          

          

            Resolver agreement
            Cloudflare, Google Public DNS, and Quad9 return the same visible PTR set.
            Different answer sets are DIFF; empty or partial agreement is PARTIAL.
          

        
      

    


    
Address scope changes severity. Public IPs are held to public reverse DNS expectations. Private IPv4 ranges, carrier-grade NAT, loopback, link-local, documentation, benchmark, multicast, reserved ranges, IPv6 unique-local, IPv6 documentation, and IPv6 link-local addresses are reported with context because their public reverse DNS behavior is often intentionally absent or environment-specific.


    

      

        
        
          

            Output
            What it contains
            Use it for
          

        
        
          

            PTR Result Ledger
            Per-IP verdict, PTR hostnames, PTR count, FCrDNS status, expected-host status, scope, TTL, query time, reason, and notes.
            Finding the exact address and rule that needs work.
          

          

            Lookup Paths
            Reverse query evidence plus forward A and AAAA evidence for each returned PTR hostname.
            Debugging why a PTR host failed to round-trip.
          

          

            Policy Checks
            Roll-up PASS, WARN, or FAIL rows for public PTR presence, FCrDNS, expected names, aliases, scoped ranges, and resolver agreement.
            Explaining the final verdict in a short operations note.
          

          

            PTR Health Mix
            A stacked chart of PASS, WARN, and FAIL counts across active check dimensions.
            Summarizing a multi-address host or mail pool.
          

        
      

    


    
Public DNS-over-HTTPS resolver services can show different cache states, timing, and TTL visibility during a change window. For authoritative change validation, treat public resolver agreement as supporting evidence and confirm the reverse zone data at the source when the result will affect a production change.

  






  

    
Privacy Notes:

    
Reverse DNS checks require network requests to public resolver services. The checked name or address-derived reverse name, DNS record type, and resolver-visible client request metadata are exposed to the selected resolver. Resolver comparison repeats the PTR lookup through Cloudflare, Google Public DNS, and Quad9. Use my IP first contacts a public IP detection service so the current public address can be inserted.


    
Do not use public resolver checks for confidential internal hostnames, unpublished address inventories, or migration targets unless that disclosure is acceptable. For private DNS, run equivalent checks from a trusted resolver inside the environment that owns the zone.

  






  

    
Worked Examples:


    
Public Resolver Address

    
Entering 8.8.8.8 should normally return a PTR hostname such as dns.google. With Forward-confirmed rDNS enabled, the useful outcome is a PTR Result Ledger row where Verdict is PASS, FCrDNS is PASS, and Scope is Public. If Expected PTR host or suffix is google, the expected-host check should match the suffix.


    
Documentation Address

    
Entering 192.0.2.10 checks an IPv4 documentation range. If no PTR answer appears, the result should emphasize Scope and the Scoped IP without PTR reason rather than treating the address like a broken public mail server. That warning is a reminder to use the right address context.


    
Mail Host With Expected Suffix

    
Entering postmaster@mail.example.com extracts the host portion, resolves its visible A and AAAA answers, then audits each IP. Setting Expected PTR host or suffix to example.com makes Expected show MATCH only when a returned PTR hostname equals that domain or ends with that suffix.


    
Recent Reverse DNS Change

    
After a provider updates a reverse zone, enable Compare reverse answers across resolvers. If Resolver Drift shows DIFF or PARTIAL, wait for caches to expire and verify the authoritative reverse zone before assuming the new PTR name is visible everywhere.

  






  

    
FAQ:


    

      Who controls a PTR record?
      
Usually the IP address owner, hosting provider, ISP, or delegated reverse DNS provider controls the reverse zone. If PTR Result Ledger shows Missing public PTR, the fix often has to happen with that provider.

    


    

      Why can a PTR hostname still fail?
      
The PTR hostname may have no A or AAAA answers, or its forward answers may not include the original IP. Open Lookup Paths to see the hostname, forward address set, and mismatch note.

    


    

      Should every IP have exactly one PTR record?
      
Not always. Strict single PTR is useful when your policy expects one stable reverse name. Without that policy, multiple PTR hostnames can still pass if the selected forward-confirmation rule is satisfied.

    


    

      Why do different resolvers disagree?
      
Resolver caches, recent changes, delegation mistakes, or inconsistent authoritative data can produce different visible answers. Use Resolver Drift as a reason to recheck later and verify the reverse zone itself.

    


    

      What should I fix when the input says no A or AAAA records were found?
      
The hostname path starts by resolving the entered host to IP addresses. If that fails, check spelling, remove an unsupported local-only name, or enter the IP address directly in IP or hostname.

    

  






  

    
Glossary:

    

      
PTR record

      
A DNS record that maps a reverse lookup name to a hostname.

      
Reverse lookup name

      
The DNS name formed from an IP address under in-addr.arpa for IPv4 or ip6.arpa for IPv6.

      
FCrDNS

      
Forward-confirmed reverse DNS, where the PTR hostname resolves forward to the original IP.

      
Resolver drift

      
A condition where compared public resolvers return different or partially empty PTR answer sets.

      
Scoped address

      
An address range such as private, loopback, link-local, documentation, carrier-grade NAT, or unique-local space where public PTR expectations differ.

      
Authoritative reverse zone

      
The delegated DNS zone that ultimately controls the PTR data for an address block.

    

  






  

    
References: