Skip to content

Reverse DNS (PTR Records) Guide

This guide explains how to create and manage Reverse DNS (PTR) records in Poweradmin for PowerDNS.

What are PTR Records?

PTR (Pointer) records provide reverse DNS resolution, mapping IP addresses to hostnames. They are used for:

  • Email server verification
  • Security controls and authentication
  • Network troubleshooting
  • Server identification

Prerequisites

Before creating PTR records, you need:

  1. The appropriate reverse zone must exist in PowerDNS
  2. For IPv4: Create a zone like 1.168.192.in-addr.arpa for the 192.168.1.0/24 network

  3. For IPv6: Create a zone like 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa for 2001:db8::/64

  4. Proper permissions to add records to these zones:

  5. You need at least one of these permissions:
    • zone_content_edit_own - To edit zones you own
    • zone_content_edit_others - To edit any zone
  6. For creating reverse zones, you need:
    • zone_master_add or zone_slave_add permissions

Reverse zones are listed separately from forward zones, under Zones → Reverse Zones.

Reverse zone list

Method 1: Adding Individual PTR Records

For single PTR records:

  1. Go to the reverse zone's record list (e.g., 1.168.192.in-addr.arpa)
  2. Click "Add Record" at the top of the zone edit page
  3. Enter the information:
  4. Name: The last octet of the IP address (e.g., 42 for 192.168.1.42)
  5. Type: PTR
  6. Content: The fully qualified domain name (FQDN) this IP should resolve to (e.g., host42.example.com.)
  7. TTL: Time-to-live value (e.g., 86400 for 1 day)
  8. Click "Add Record"

Adding an individual PTR record

Method 2: Using Batch PTR Records Feature

For creating multiple PTR records at once:

  1. Access the Batch PTR Records feature:
  2. From the top navigation: Zones → Batch PTR Records

  3. From the dashboard: Click the "PTR Records" card

  4. Complete the form:

  5. IP Version: Choose IPv4 or IPv6
  6. Network Prefix: The network in CIDR notation (e.g., 192.168.1.0/24 or 10.0.0.0/20). The button beside the field picks from the reverse zones you already have.
  7. Host Prefix: Base name for the hosts (e.g., server). Leave empty to use just the domain.
  8. Domain: Domain suffix for PTR records (e.g., example.com)
  9. Comment: Optional, stored on each created record
  10. Create forward A/AAAA records in primary zone: Also creates the matching forward records
  11. Create PTRs only for existing A/AAAA records in forward zone: Restricts creation to IPs that already resolve, instead of the whole range

The form has no TTL or Priority fields. It shows a "Using default TTL value from configuration" note, the TTL is resolved server-side, and the priority is always 0.

  1. Click "Create PTR Records"

Batch PTR Records interface

Examples

IPv4 Example

  • Network Prefix: 192.168.1
  • Host Prefix: server
  • Domain: example.com

This will create 254 PTR records - the network address (.0) and the broadcast address (.255) are skipped:

  • 1.1.168.192.in-addr.arpa → server1.example.com.
  • 2.1.168.192.in-addr.arpa → server2.example.com.
  • ...through...
  • 254.1.168.192.in-addr.arpa → server254.example.com.

IPv4 Batch PTR Records example

IPv6 Example

  • Network Prefix: 2001:db8:1:1
  • Host Prefix: vm
  • Domain: example.com
  • IPv6 Count: 100

This will create 99 PTR records - index 0 is skipped, and the suffix is written in hexadecimal, so the addresses run from 2001:db8:1:1::1 to 2001:db8:1:1::63 with hostnames vm1.example.com through vm63.example.com.

IPv6 Batch PTR Records example

Tips for Batch PTR Records

  • Run Multiple Times Safely: You can run the batch tool multiple times - existing records will be skipped
  • Progress Reporting: The tool reports how many records were created, skipped, or failed
  • Reverse Zone Required: The appropriate reverse zone must exist before using this feature
  • Automated Creation: All hostnames are generated automatically based on the pattern {prefix}{number}.{domain} - no separator is inserted between the prefix and the number, and for IPv6 the number is hexadecimal

Permissions and Access Control

The Batch PTR Records feature follows Poweradmin's permission system:

  1. Required Feature Flag:

  2. The add_reverse_record option must be enabled in the Poweradmin configuration

  3. Required User Permissions:

  4. Either the zone_content_edit_own or zone_content_edit_others permission is required to access this feature

  5. When accessed from a specific zone page, you also need ownership of that zone (if using zone_content_edit_own)

  6. Permission Hierarchy:

  7. zone_content_edit_others gives access to all zones
  8. zone_content_edit_own limits access to zones you own

  9. No edit permissions means no access to batch PTR records

  10. Administrative Setup:

  11. Administrators can assign these permissions through permission templates
  12. The navigation entry is shown to anyone with a zone content view permission, so view-only users still see "Batch PTR Records" in the Zones menu - they are refused with a permission error when they open it

Troubleshooting

  • No matching reverse zone found: Create the appropriate reverse zone first
  • Permission denied: Ensure you have rights to add records to the reverse zone
  • No records created: Check if records already exist (they will be skipped)
  • Feature not visible: Check if you have the required permissions

Delegating a Sub-Range (RFC 2317)

When you own a /24 reverse zone but want a different team or client to manage PTRs for only part of it (e.g. 10.0.0.64/26), use classless reverse delegation as defined in RFC 2317. Poweradmin's ownership model is per-zone, so the trick is to create a smaller child zone for the sub-range and assign it to the delegate.

Example: Delegate 10.0.0.64/26 to a client

Parent zone: 0.0.10.in-addr.arpa (owned by you, covers 10.0.0.0/24). Goal: the client manages PTRs for 10.0.0.64 through 10.0.0.127.

1. Create the child zone

From Zones → Add master zone, create:

  • Zone name: 64/26.0.0.10.in-addr.arpa (slash notation - preferred)
    • Range notation 64-127.0.0.10.in-addr.arpa is also accepted.
  • Owner: the client user (or a group the client belongs to)

Poweradmin's hostname validator accepts both notations. The slash form follows the RFC 2317 example syntax most resolvers and dig output assume.

Note: In slash notation the subnet number must be aligned with the prefix length. 64/26 is accepted because 64 is a multiple of the /26 block size of 64. 64/25 is rejected with "Subnet 64 is not aligned with prefix /25" - a /25 block is 128 addresses and starts only at 0 or 128. Range notation is not checked for alignment.

2. Add delegation NS records in the child zone

In the new child zone, add NS records pointing to whichever nameservers will be authoritative for it (often the same servers as the parent).

3. Add CNAME glue in the parent zone

In 0.0.10.in-addr.arpa, replace the PTR records for the 64-127 range with CNAMEs pointing into the child zone. For each delegated address:

Name Type Content
64 CNAME 64.64/26.0.0.10.in-addr.arpa.
65 CNAME 65.64/26.0.0.10.in-addr.arpa.
... ... ...
127 CNAME 127.64/26.0.0.10.in-addr.arpa.

These CNAMEs tell any resolver doing reverse lookup for 10.0.0.64-127 to chase the answer into the delegated child zone.

4. Client adds PTRs in the child zone

The client (who owns the child zone, not the parent) adds PTR records in 64/26.0.0.10.in-addr.arpa:

Name Type Content
64 PTR host64.client.example.
100 PTR mailrelay.client.example.

The client cannot edit the parent zone, and you cannot accidentally clobber their PTRs.

When you don't need RFC 2317

If you're delegating on an octet boundary - the whole /24 inside a /16, for instance - just create the child zone directly (5.10.in-addr.arpa under 10.in-addr.arpa) and assign the owner. No CNAMEs needed.

RFC 2317 only applies when the sub-range doesn't align with a DNS label boundary, i.e. anything smaller than /24 for IPv4 or anything not on a nibble boundary for IPv6.

Per-Record-Type Default TTLs (4.5.0)

Admins can configure default TTLs per record type on the TTL defaults page (/tools/record-type-defaults). There is no Tools menu entry for it - open it from the "TTL defaults" card on the dashboard or go to the URL directly. Values stored there take precedence over the legacy dns.ttl_reverse config and dns.ttl fallback. The same default applies to every record-creation path (UI forms, batch PTR, the record APIs, RRSets, bulk records, and the DNS wizard) when the caller omits a ttl field. Leave a row empty to fall back to the legacy chain.

The fallback chain (first non-null wins):

  1. record_type_defaults row for the submitted type (admin-managed via the UI above)
  2. dns.ttl_reverse for PTR records in reverse zones (legacy config)
  3. dns.ttl

Default TTL for PTR Records (legacy)

dns.ttl_reverse in config/settings.php is the legacy config-file knob that predates the per-type table. It still works as a fallback when no per-type row is configured: when set, it pre-fills the TTL field on the add-record form for reverse zones, applies to batch PTR creation, and is used for PTRs auto-created alongside a forward record. When unset, PTRs fall back to dns.ttl. Originally added in 4.4.0; extended to the record APIs, RRSets, bulk records, and the DNS wizard in 4.5.0.

'dns' => [
    'ttl' => 86400,
    'ttl_reverse' => 300, // 5 minutes for all PTR records
],

Best Practices

  1. Use meaningful host prefixes that identify the purpose of the servers
  2. Use consistent TTL values across your reverse zones
  3. Ensure your forward (A/AAAA) and reverse (PTR) records match
  4. Consider using shorter TTLs during migration periods