{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
Enter the delegated IPv4 range, for example 192.0.2.128/28 or 10.20.30.0/24.
Use the forward DNS zone for PTR targets, such as corp.example or example.internal.
Seconds accepted; 300, 3600, and 86400 are common values.
seconds
Use an authoritative nameserver hostname; relative labels are expanded under the forward hostname suffix.
Enter hostmaster@corp.example or hostmaster.corp.example.; the zone uses SOA RNAME syntax.
Use an increasing unsigned 32-bit value, for example 2026050401.
Enter one hostname per line; at least two nameservers are recommended for delegated public zones.
Use CSV rows such as 192.0.2.130,mail.corp.example. or 131,vpn; blank hostnames use the fallback pattern.
Rows stay local and update the zone text immediately.
Hyphen style avoids slash handling surprises during zone transfers; slash style matches many RFC2317 examples.
PTR entries only is smallest; usable range prepares the whole delegated host range.
Keep the default for predictable hostnames, or enter a naming pattern such as node-{offset}.{domain}.
Keep first prevents accidental multi-PTR answers; keep all is available for intentional aliases.
Leave on for predictable zone diffs and reviewer-friendly exports.
{{ sort_records ? 'On' : 'Off' }}
Seconds accepted; 3600 is a common default for small zones.
seconds
Keep retry shorter than refresh so temporary transfer failures recover quickly.
seconds
Use a value comfortably larger than refresh and retry.
seconds
Use a value aligned with your negative caching policy.
seconds
Turn off when you need only zone directives and resource records in the exported file.
{{ include_comments ? 'On' : 'Off' }} 
{{ result.zoneText }}
{{ result.parentText }}
IPv4 Owner PTR target TTL Source Copy
{{ row.ip }} {{ row.owner }} {{ row.target }} {{ row.ttl }} {{ row.source }}
No valid PTR rows are ready for export.
Severity Check Current Action Copy
{{ row.severity }} {{ row.check }} {{ row.current }} {{ row.action }} 

        

      


    

  

                

                

                    

                        

                            Tags: DNS, Devtools, Networking
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
    
Reverse DNS for IPv4 maps an address back to a host name by placing PTR records under the in-addr.arpa namespace. The address labels are written in reverse octet order, so 192.0.2.130 is looked up below 130.2.0.192.in-addr.arpa. That reversed structure lets DNS authority follow address ownership instead of the forward domain name.

    
Administrators use reverse DNS for mail server reputation checks, network logs, asset inventories, monitoring alerts, and service records that need a readable name for an IP address. A good PTR record does not prove who controls a server, but it helps tools and people connect an address to the intended hostname.


    

      
        
        
          
            
          
        
        
          
          IPv4 address
          192.0.2.130

          
          Reverse owner
          130.2.0.192...

          
          PTR target
          mail.example.

          
          

          
          /24 direct zone
          one owner label per host

          
          /25 to /32 child zone
          parent CNAME points inward

          
        
      
      
A normal IPv4 PTR lookup follows the reversed address tree. Smaller delegated ranges often need an RFC2317 child zone plus parent-zone CNAME records.

    


    
Reverse zones become simple when the delegation lands on an octet boundary such as /24, /16, or /8. Smaller IPv4 ranges are common in hosting and ISP allocations, and they need a classless delegation pattern so the parent reverse zone can point individual address owners into a child zone.

    
A generated reverse zone is still a draft. It can make the zone origin, SOA values, PTR rows, and parent delegation snippet easier to review, but the organization that controls the parent reverse zone must publish the matching delegation records before public resolvers can follow them.

  






  

    
Technical Details

    
IPv4 reverse DNS uses a tree built from octets. The most specific host owner has four decimal labels before in-addr.arpa, with the last address octet written first. A PTR record at that owner points to the preferred host name, normally a fully qualified domain name with a trailing dot in zone-file form.

    
The reverse zone origin depends on the delegation boundary. For 192.0.2.0/24, the origin is 2.0.192.in-addr.arpa. and each PTR owner is the final octet. For /16 and /8, more owner labels remain inside the zone because fewer octets are fixed by the origin.

    
Classless IPv4 delegations use an extra child label under the parent /24 reverse zone. The parent publishes NS records for the child and CNAME records for the covered address owners. The child zone then contains the PTR records. That parent link is not cosmetic; without it, resolvers do not reach the child PTR records through the normal reverse lookup path.


    
Rule Core

    
The generator builds one of three reverse-zone strategies from the CIDR prefix. Octet-boundary ranges produce direct reverse zones, longer-than-/24 ranges produce an RFC2317 child zone, and non-octet ranges between those cases are emitted as a parent-zone fragment with a warning.


    

      

        
        
          

            CIDR shape
            Zone strategy
            Owner labels inside the generated zone
            Parent snippet
          

        
        
          

            /24
            Standard reverse zone such as 2.0.192.in-addr.arpa.
            Final octet, such as 130
            Not required by this strategy
          

          

            /16
            Standard reverse zone at the second-octet boundary
            Two reversed host octets
            Not required by this strategy
          

          

            /8
            Standard reverse zone at the first-octet boundary
            Three reversed host octets
            Not required by this strategy
          

          

            /25 to /32
            RFC2317 child zone below the parent /24
            Final octet inside the child zone
            NS records for the child plus CNAME records for selected addresses
          

          

            /9 to /23 when not on an octet boundary
            Parent-zone fragment with a review warning
            Remaining reversed octets below the nearest safe parent origin
            Not generated as an RFC2317 child
          

        
      

    


    
Transformation Core

    
The output starts with the reverse origin and default TTL, then writes the SOA header, authoritative nameservers, and sorted PTR rows. For classless ranges, the parent snippet is generated beside the child zone so the delegation records can be reviewed as a pair.


    

      

        
        
          

            Stage
            Input shape
            Generated result
          

        
        
          

            CIDR parsing
            IPv4 subnet in CIDR notation from /8 through /32
            Network base, broadcast address, address count, and reverse-zone strategy
          

          

            Authority block
            Primary nameserver, responsible mailbox, serial, NS list, and SOA timers
            $ORIGIN, $TTL, apex SOA, and apex NS records
          

          

            PTR rows
            CSV rows in address,hostname,ttl,note form
            One PTR record per retained row, with optional per-row TTL
          

          

            Blank hostnames
            PTR row with an address but no hostname
            Fallback target from tokens such as {last}, {offset}, {ip}, and {domain}
          

          

            RFC2317 parent records
            Classless child label plus selected parent coverage
            Child NS records and parent CNAME stubs pointing into the child zone
          

          

            Review output
            Errors, warnings, notes, normalized values, and generated rows
            Zone checks, PTR ledger, parent snippet, reverse-zone text, and structured JSON
          

        
      

    


    
Validation Boundaries

    
Several checks protect the generated file from common DNS mistakes. They are not a replacement for server-side linting, but they make the draft easier to review before it reaches an authoritative name server.


    

      

        
        
          

            Area
            Boundary used here
            Review impact
          

        
        
          

            Subnet
            CIDR must contain a valid IPv4 address and a prefix from /8 to /32. Host bits are normalized to the network base.
            Prevents a reverse origin from being built from a non-network address.
          

          

            TTL and SOA timers
            Whole seconds from 0 to 2147483647.
            Keeps cache and transfer timers within the accepted numeric range.
          

          

            Serial
            Digits only, unsigned 32-bit maximum, with a warning when it is not shaped like YYYYMMDDnn.
            Helps secondary servers detect updates after the zone is reloaded.
          

          

            Names
            Forward suffix, nameservers, mailbox domain, and PTR targets are normalized as DNS names.
            Reduces mistakes from URLs, missing trailing dots, mailbox input, or mixed-case hostnames.
          

          

            PTR address scope
            PTR row addresses must fall inside the parsed subnet.
            Stops an address from being written into the wrong reverse zone.
          

          

            Duplicates
            Duplicate address rows can keep the first row, keep the last row, or keep all rows.
            Supports conservative one-PTR-per-address drafts while allowing intentional aliases.
          

        
      

    


    
PTR accuracy depends on data outside the reverse zone too. Many operational checks compare the PTR target with forward A or AAAA records, and the parent reverse zone must match the child nameservers when RFC2317 delegation is used.

  






  

    
Everyday Use & Decision Guide

    
Start with the delegated IPv4 subnet and the forward hostname suffix. The subnet decides the reverse origin and whether a parent CNAME snippet is needed; the suffix fills relative PTR targets and fallback hostnames such as vpn or db01.

    
Use full hostnames with trailing dots when the PTR target already lives outside the suffix. Use relative names when every target should sit under the same forward domain. If a PTR row has an address and no hostname, the fallback pattern can create predictable names from the final octet, offset, full IP address, and domain.

    
The advanced settings matter most for classless ranges and operational review. Hyphen, slash, and dot classless labels change the child zone name used for RFC2317 records. Parent CNAME coverage can stay limited to PTR entries, expand across usable addresses, or cover every address in the subnet. Duplicate handling should usually stay on "keep first" unless multiple PTR answers for one address are intentional.

    
Rows are processed in the browser as the zone text updates. Before copying the result, open Zone Checks and clear any blocking input rows. Warnings are not always fatal, but a single nameserver, a primary nameserver missing from the NS list, a serial that does not follow the usual date pattern, or classless output without parent coordination should slow the rollout down.

    
After the draft looks right, copy or download the Reverse Zone output, then handle Parent CNAMEs if the strategy says RFC2317 child. The last production step should still be a DNS linter such as named-checkzone and a delegation check against the parent reverse zone.

  






  

    
Step-by-Step Guide

    
    
      
  1. Enter the IPv4 subnet in CIDR notation, using the range that is actually delegated to you.
    2. 
      
  2. Set the forward hostname suffix, primary nameserver, responsible mailbox, serial, default TTL, and authoritative nameserver list.
    3. 
      
  3. Add PTR entries as CSV rows. Each row can use a full IPv4 address or a final octet when that fits the selected range.
    4. 
      
  4. Open Advanced when the subnet is smaller than /24 or when duplicate policy, fallback naming, SOA timers, sorting, or parent CNAME coverage needs adjustment.
    5. 
      
  5. Review the summary status, Zone Checks tab, PTR Ledger, reverse-zone text, and Parent CNAMEs tab.
    6. 
      
  6. Copy or download the generated files only after the origin, nameservers, serial, PTR targets, and parent delegation snippet match the intended DNS change.
    7. 
    

  






  

    
Interpreting Results

    
The summary shows the reverse-zone origin when the draft is usable enough to review. A "Needs edits" status means a blocking input problem is present. "Review warnings" means the text may still be generated, but at least one operational issue needs a human decision. "Ready to lint" means the built-in checks found no blocking errors or warnings.

    
The Reverse Zone tab is the child or direct zone file text. It includes comments when that option is enabled, then the origin, TTL, SOA, NS records, and PTR rows. The Parent CNAMEs tab is only actionable for RFC2317 output; for direct zones it explains that parent CNAMEs are not required by the chosen strategy.

    
The PTR Ledger is the easiest place to audit address-by-address output because it separates IPv4 address, owner label, PTR target, TTL, and source note. Zone Checks gives the same review in risk order: blocking input, zone warnings, normalization notes, origin summary, PTR coverage, SOA header, and authoritative NS count.

    
The JSON tab is useful for change records or peer review because it includes the inputs, generated reverse-zone plan, nameservers, PTR records, parent delegation summary, checks, and final zone text in one structured payload.

  






  

    
Worked Examples

    
Standard /24 Reverse Zone

    
For 192.0.2.0/24, the reverse origin is 2.0.192.in-addr.arpa.. A PTR row such as 192.0.2.130,mail.corp.example. becomes an owner of 130 inside that zone and points to mail.corp.example..

    

      

        
        
          

            Input
            Generated owner
            PTR target
          

        
        
          

            192.0.2.130,mail.corp.example.
            130
            mail.corp.example.
          

          

            131,vpn
            131
            vpn.corp.example.
          

        
      

    


    
RFC2317 /28 Child Zone

    
For 192.0.2.128/28, the child label can be 128-28, 128/28, or 128.28 depending on the selected style. With the hyphen style, the child origin becomes 128-28.2.0.192.in-addr.arpa.. A PTR for 192.0.2.130 lives at owner 130 inside the child, while the parent zone needs a CNAME from 130 to 130.128-28.2.0.192.in-addr.arpa..

    

      

        
        
          

            Part
            Example output
            Where it belongs
          

        
        
          

            Child origin
            128-28.2.0.192.in-addr.arpa.
            Your delegated reverse zone
          

          

            Child PTR
            130 IN PTR mail.corp.example.
            Child reverse zone
          

          

            Parent CNAME
            130 IN CNAME 130.128-28.2.0.192.in-addr.arpa.
            Parent 2.0.192.in-addr.arpa. zone
          

        
      

    

  






  

    
FAQ

    
Does the generator support IPv6 reverse DNS?

    
No. The current generator is IPv4-only and emits in-addr.arpa zones, not IPv6 ip6.arpa nibble zones.


    
Why does a smaller-than-/24 range need parent CNAME records?

    
The IPv4 reverse tree delegates naturally on octet boundaries. RFC2317 uses CNAME records in the parent /24 zone to point each covered address into the smaller child zone.


    
Can one IP address have more than one PTR record?

    
DNS can return multiple PTR records for one owner, but many operational checks expect one clear name per address. Keep-first duplicate handling is the safer default unless multiple names are an intentional policy choice.


    
Why does the responsible mailbox change form?

    
The SOA responsible mailbox uses DNS RNAME syntax. An email address such as hostmaster@example.com becomes hostmaster.example.com., and dots in the local part are escaped.


    
Is the generated zone ready to publish immediately?

    
Use it as a draft. Clear blocking checks, review warnings, confirm parent delegation for RFC2317 output, verify forward and reverse consistency, and run the final text through the DNS server's zone checker before publishing.

  






  

    
Glossary

    

      
PTR record

      
A DNS record that maps a reverse DNS owner name to a host name.

      
Reverse origin

      
The in-addr.arpa zone name under which the PTR owners are written.

      
SOA record

      
The Start of Authority record that carries the primary nameserver, responsible mailbox, serial, and timer values for the zone.

      
RFC2317

      
The common classless IPv4 reverse delegation method that uses child reverse zones and parent CNAME records.

      
Parent CNAME

      
A CNAME in the parent reverse zone that points an address owner into a delegated child zone.

    

  






  

    
References