Dual-Stack Reverse DNS: RFC 2317 and ip6.arpa Setup

Published: 25 Sep, 2026

The Mechanics of Dual-Stack Reverse Delegation

Reverse DNS (rDNS) resolution maps an IP address back to a fully qualified domain name (FQDN) via PTR records. In dual-stack environments handling egress SMTP, custom BGP routing, or strict TLS authentication, Forward-Confirmed Reverse DNS (FCrDNS) is strictly enforced. When an outbound mail node establishes a connection, receiving MTAs verify that the IP resolves to a hostname, and that the hostname resolves back to that identical IP address.

Standard IPv4 reverse zones operate on byte boundaries using in-addr.arpa. A full /24 subnet neatly aligns with one octet (e.g., 198.51.100.0/24 maps to 100.51.198.in-addr.arpa). However, allocations smaller than a /24 (such as /28 or /29) cannot be delegated cleanly at the octet boundary. To resolve this, RFC 2317 defines classless IPv4 reverse delegation using intermediate CNAME resource records. Concurrently, IPv6 uses the ip6.arpa domain where every hexadecimal character (nibble) represents a 4-bit boundary, requiring 32 inverted nibbles separated by dots.

Classless IPv4 Reverse DNS (RFC 2317)

When an upstream ISP or Regional Internet Registry (RIR) assigns a sub-/24 block (e.g., 198.51.100.64/28), they maintain authoritative control over 100.51.198.in-addr.arpa. To delegate authority of IPs .64 through .79 to your authoritative nameservers, the parent zone introduces a CNAME alias pointing to a custom child zone.

Parent Zone Setup (Upstream ISP)

In the upstream zone file, each individual host record contains a CNAME pointing to an address within a sub-zone labeled by the subnet notation or offset:

; Parent zone: 100.51.198.in-addr.arpa
$ORIGIN 100.51.198.in-addr.arpa.

; Subnet delegation for 198.51.100.64/28
64/28    IN NS ns1.example.com.
64/28    IN NS ns2.example.com.

; Alias pointers for the /28 range
64       IN CNAME 64.64/28.100.51.198.in-addr.arpa.
65       IN CNAME 65.64/28.100.51.198.in-addr.arpa.
66       IN CNAME 66.64/28.100.51.198.in-addr.arpa.
; [...]
79       IN CNAME 79.64/28.100.51.198.in-addr.arpa.

Child Zone Setup (Authoritative Nameserver)

On your authoritative DNS servers (e.g., BIND9, NSD, or PowerDNS), create the corresponding zone matching the delegated label 64/28.100.51.198.in-addr.arpa:

; Child zone: 64/28.100.51.198.in-addr.arpa
$TTL 86400
$ORIGIN 64/28.100.51.198.in-addr.arpa.
@   IN SOA ns1.example.com. hostmaster.example.com. (
           2026092501 ; Serial
           7200       ; Refresh
           3600       ; Retry
           1209600    ; Expire
           3600 )     ; Negative Cache TTL

    IN NS  ns1.example.com.
    IN NS  ns2.example.com.

; Actual PTR definitions
65  IN PTR mail.example.com.
66  IN PTR edge01.example.com.
67  IN PTR vpn.example.com.

IPv6 Reverse DNS: The ip6.arpa Structure

IPv6 reverse lookups do not require the RFC 2317 translation trick because IPv6 subnets delegate strictly along 4-bit nibble boundaries. A standard /48 or /64 allocation directly matches 12 or 16 hex characters respectively.

Consider the IPv6 prefix 2001:db8:85a3::/48. To determine the reverse origin, expand the address fully into 32 hex nibbles, reverse the sequence, and append ip6.arpa.

Prefix / Address	Expanded Hex	Reverse Delegation Zone
2001:db8:85a3::/48	2001:0db8:85a3	3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.
2001:db8:85a3:1::/64	2001:0db8:85a3:0001	1.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.
2001:db8:85a3:1::50	Host ::50 in /64	0.5.0.0...1.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.

Authoritative IPv6 Zone Configuration

Below is a production-ready BIND9 zone file for a delegated /64 prefix:

; Zone: 1.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.
$TTL 86400
$ORIGIN 1.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa.
@   IN SOA ns1.example.com. hostmaster.example.com. (
           2026092501 ; Serial
           7200       ; Refresh
           3600       ; Retry
           1209600    ; Expire
           3600 )     ; Negative Cache TTL

    IN NS  ns1.example.com.
    IN NS  ns2.example.com.

; Host: 2001:db8:85a3:1::25 (mail.example.com)
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail.example.com.

; Host: 2001:db8:85a3:1::100 (edge01.example.com)
0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR edge01.example.com.

Validating Dual-Stack FCrDNS Resolution

To ensure MTAs and security policies accept connections from your hosts, verify that the forward resolution and reverse lookup match symmetrically on both protocols.

1. Testing IPv4 RFC 2317 Resolution Path

Query your nameserver for the PTR record using dig to observe the CNAME chasing mechanism:

dig +trace -x 198.51.100.65

The query returns an initial CNAME answer followed by the delegated PTR:

;; ANSWER SECTION:
65.100.51.198.in-addr.arpa. 86400 IN CNAME 65.64/28.100.51.198.in-addr.arpa.
65.64/28.100.51.198.in-addr.arpa. 86400 IN PTR mail.example.com.

2. Testing IPv6 Reverse Resolution

Perform the pointer query directly against the target IPv6 node:

dig -x 2001:db8:85a3:1::25 +short

Expected output:

mail.example.com.

3. Confirming Forward Matching

Confirm that the resolved canonical name advertises both corresponding forward records:

dig mail.example.com A +short
dig mail.example.com AAAA +short

Output must return:

198.51.100.65
2001:db8:85a3:1::25

Common Dual-Stack Delegation Pitfalls

• Origin Mismatches in RFC 2317: Omitting the trailing dot on the parent CNAME record (e.g., writing 65.64/28.100.51.198.in-addr.arpa without a trailing dot) appends the root zone name twice, breaking resolution.
• IPv6 Nibble Truncation: Forgetting zero-padding in hexadecimal blocks (e.g., resolving :25 as 5.2. instead of full 16 host nibbles 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0).
• TTL Desynchronization: Setting high TTL values on reverse zones during migrations. Keep PTR TTLs at 3600 seconds during rollout to quickly remediate routing mismatches.