Fixing Dual-Stack IPv4/IPv6 rDNS & PTR Delegation
Published: 27 Aug, 2026

blog_6GCQauDbBt3S28oPuL-RiAM_thumb.jpg

Forward-Confirmed Reverse DNS in Dual-Stack Architectures

Modern edge infrastructure, particularly mail transfer agents (MTAs) and secure API gateways, requires stringent Forward-Confirmed Reverse DNS (FCrDNS) validation. When an external host receives an inbound connection over either IPv4 or IPv6, it queries the connecting IP address against the DNS reverse hierarchy (in-addr.arpa or ip6.arpa). If the resulting PTR record does not resolve back to that identical IP address via an A or AAAA record, traffic is routinely throttled, flagged as spam, or rejected at the edge.

Misconfigurations commonly occur when deploying dual-stack nodes on subnets smaller than an IPv4 /24 or when handling the 32-nibble structure required by ip6.arpa.

Resolving Classless IPv4 Delegation (RFC 2317)

When an ISP assigns a CIDR block smaller than a class C (such as a /29 or /28), they cannot simply delegate the entire octet zone (e.g., 0.168.192.in-addr.arpa) to your authoritative nameservers. Instead, the upstream provider must implement RFC 2317 classless in-addr.arpa delegation using CNAME resource records.

Upstream Provider Zone Configuration

The upstream ISP manages the full /24 zone and creates alias records for your assigned host boundary. For an assigned range 198.51.100.64/29, the upstream zone defines:

$ORIGIN 100.51.198.in-addr.arpa.
64/29    IN NS  ns1.example.com.
64/29    IN NS  ns2.example.com.

65       IN CNAME 65.64/29.100.51.198.in-addr.arpa.
66       IN CNAME 66.64/29.100.51.198.in-addr.arpa.
67       IN CNAME 67.64/29.100.51.198.in-addr.arpa.

Authoritative Server Subnet Zone (BIND 9)

On your authoritative nameservers (ns1.example.com), you define the matching zone in named.conf:

zone "64/29.100.51.198.in-addr.arpa" {
    type master;
    file "/var/named/db.198.51.100.64-29";
};

Inside the master file /var/named/db.198.51.100.64-29, assign the target PTR records using the relative host offsets:

$TTL 86400
$ORIGIN 64/29.100.51.198.in-addr.arpa.
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2026082701 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; negative cache TTL

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

65  IN  PTR mail.example.com.
66  IN  PTR edge.example.com.

Constructing IPv6 ip6.arpa Zones

Unlike IPv4 dot-decimal representations, IPv6 reverse DNS expands the entire 128-bit address into thirty-two 4-bit hexadecimal nibbles, delimited by periods and reversed under the ip6.arpa top-level domain.

For a host with the address 2001:db8:4a00:1001::5, the full 32-nibble expanded form is:

2.0.0.1.0.d.b.8.4.a.0.0.1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.5

IPv6 Zone Configuration (BIND 9)

For a delegated /64 prefix (e.g., 2001:db8:4a00:1001::/64), create the zone entry in named.conf by reversing the first 16 nibbles:

zone "1.0.0.1.0.0.a.4.8.b.d.0.1.0.0.2.ip6.arpa" {
    type master;
    file "/var/named/db.2001.db8.4a00.1001";
};

In the corresponding master zone file, define the remaining 16 nibbles for each interface address:

$TTL 86400
$ORIGIN 1.0.0.1.0.0.a.4.8.b.d.0.1.0.0.2.ip6.arpa.
@   IN  SOA ns1.example.com. hostmaster.example.com. (
        2026082701 ; serial
        7200       ; refresh
        3600       ; retry
        1209600    ; expire
        86400 )    ; minimum TTL

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

; 2001:db8:4a00:1001::5
5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail.example.com.

Diagnostic Verification with CLI Utilities

Validate the delegation chain and test bidirectional resolution from an external resolver using dig and host.

Step 1: Test IPv4 Classless Resolution

dig +trace -x 198.51.100.65

Verify that the output contains the intermediate CNAME referral followed by the terminal PTR pointing to mail.example.com.

Step 2: Test IPv6 Reverse Resolution

dig -x 2001:db8:4a00:1001::5 @8.8.8.8 +short

The return value must match the exact canonical hostname: mail.example.com.

Step 3: Confirm Forward Consistency (FCrDNS)

Query the forward records of the returned hostname to guarantee mutual alignment across both address families:

host mail.example.com

Ensure the output includes both:

mail.example.com has address 198.51.100.65
mail.example.com has IPv6 address 2001:db8:4a00:1001::5

If the forward lookup fails to list the original IP for either protocol, remote SMTP and security daemons will drop the connection due to failed reverse path verification.