Fixing RFC 2317 Classless Reverse DNS Delegation
Published:
13 Oct, 2026
When an upstream ISP delegates a classful IPv4 block—such as an entire /24—reverse DNS delegation is straightforward: the registry or upstream provider delegates the corresponding in-addr.arpa octet boundary directly to your authoritative nameservers via NS records. However, when allocating subnets smaller than a /24 (such as a /29, /28, or /27), standard octet boundaries cannot accommodate conventional delegation.
To solve this, RFC 2317 defines a standard mechanism using CNAME resource records inside the parent /24 zone that point to a distinct subzone delegated to the customer authoritative servers. When reverse lookups fail with NXDOMAIN or SERVFAIL on assigned static IPs, the breakdown typically occurs in the contractual link between the upstream provider CNAME pointer and the customer child zone definition.
The RFC 2317 Architecture
Understanding where a resolution path breaks requires inspecting both sides of the delegation boundary. Assume an ISP assigns the subnet 198.51.100.64/29 (usable host addresses 198.51.100.65 through 198.51.100.70) to an enterprise infrastructure.
1. The Upstream (Parent) Zone: 100.51.198.in-addr.arpa
The upstream provider controls the full classful octet zone (100.51.198.in-addr.arpa). Because they cannot place customer NS records directly on individual host octet labels (e.g., 65.100.51.198.in-addr.arpa), the ISP establishes:
- Individual CNAME records for each allocated IP pointing to a synthetic subzone.
- NS records delegating that entire synthetic subzone to the customer authoritative nameservers.
; Upstream ISP Zone: 100.51.198.in-addr.arpa
$ORIGIN 100.51.198.in-addr.arpa.
; Delegation of the /29 subnet namespace to customer nameservers
64/29 IN NS ns1.customerdomain.com.
64/29 IN NS ns2.customerdomain.com.
; CNAME aliases pointing individual IPs into the delegated subzone
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.
68 IN CNAME 68.64/29.100.51.198.in-addr.arpa.
69 IN CNAME 69.64/29.100.51.198.in-addr.arpa.
70 IN CNAME 70.64/29.100.51.198.in-addr.arpa.Note: While RFC 2317 suggests the slash notation (64/29), many ISPs use hyphens (64-29), subnet base numbers alone (64), or custom labels. Any delimiter is technically valid as long as both parent and child zones use the identical syntax.
2. The Downstream (Child) Zone: 64/29.100.51.198.in-addr.arpa
On your authoritative nameservers (e.g., running BIND9, PowerDNS, or NSD), you must host the exact subzone name specified by the ISP. Inside this subzone, host records map back to their intended Fully Qualified Domain Names (FQDNs):
; Customer Child Zone: 64/29.100.51.198.in-addr.arpa
$ORIGIN 64/29.100.51.198.in-addr.arpa.
$TTL 86400
@ IN SOA ns1.customerdomain.com. hostmaster.customerdomain.com. (
2024050101 ; Serial
7200 ; Refresh (2 hours)
3600 ; Retry (1 hour)
1209600 ; Expire (2 weeks)
86400 ; Minimum TTL (1 day)
)
@ IN NS ns1.customerdomain.com.
@ IN NS ns2.customerdomain.com.
; PTR records corresponding to host octets
65 IN PTR mail.customerdomain.com.
66 IN PTR vpn.customerdomain.com.
67 IN PTR web.customerdomain.com.Step-by-Step Diagnostic Workflow
When an outbound mail transfer agent (MTA) or authentication service fails a PTR check on 198.51.100.65, run the following sequential diagnostics using dig to pinpoint the exact broken link.
Step 1: Check the Upstream CNAME Chain
Bypass local recursive caches and query the ISP authoritative nameservers directly. First, identify the authoritative nameservers for the parent /24:
dig +short NS 100.51.198.in-addr.arpaSelect one of the returned upstream nameservers (for example, ns1.isp-backbone.net) and query for the PTR record of the target host:
dig @ns1.isp-backbone.net PTR 65.100.51.198.in-addr.arpa +norecurseExamine the response:
- Expected Result: An ANSWER: 1 containing the CNAME record (e.g.,
65.100.51.198.in-addr.arpa. IN CNAME 65.64/29.100.51.198.in-addr.arpa.) and an AUTHORITY section containing NS records pointing to your nameservers. - Failure Case 1 (NXDOMAIN): The ISP never generated the CNAME record for this specific host IP.
- Failure Case 2 (No CNAME, Direct PTR/Empty): The ISP misconfigured the block as a conventional /24 without delegation.
Step 2: Verify Customer Authoritative Response
Next, isolate your authoritative nameservers by querying them directly for the target of the CNAME chain discovered in Step 1:
dig @ns1.customerdomain.com PTR 65.64/29.100.51.198.in-addr.arpa +norecurseExamine the flags and status:
- Expected Result:
status: NOERROR, flags containingaa(Authoritative Answer), and an answer section:65.64/29.100.51.198.in-addr.arpa. IN PTR mail.customerdomain.com. - Failure Case 1 (status: REFUSED): Your DNS daemon is running, but it does not have the zone loaded or view access is restricted to internal clients.
- Failure Case 2 (status: NXDOMAIN): Zone naming mismatch. If the ISP CNAME points to
65.64-29...(hyphen) and your configuration defines64/29...(slash), the server cannot match the query to the zone origin. - Failure Case 3 (Timeout): UDP/TCP port 53 firewall blocks on your perimeter preventing queries from external IPs.
Step 3: End-to-End Recursive Verification
Once both authoritative legs answer correctly, verify how recursive resolvers trace the link from root to target:
dig +trace -x 198.51.100.65The trace must show the resolution hopping from the root nameservers to the Regional Internet Registry (ARIN/RIPE/APNIC), down to the ISP nameservers (receiving the CNAME), and finally completing at your authoritative servers with the terminal PTR record.
Common RFC 2317 Implementation Pitfalls
| Symptom | Underlying Technical Cause | Resolution |
|---|---|---|
| SERVFAIL on recursive lookups | ISP delegates subzone via NS records, but customer nameservers drop or reject port 53 UDP/TCP traffic. | Ensure customer firewalls allow inbound UDP/TCP 53 and verify that BIND/PowerDNS binds to public WAN interfaces. |
| Trailing dot missing in zone file | Target in CNAME or child PTR lacks trailing dot (e.g., mail.customerdomain.com without .). |
BIND appends the $ORIGIN, producing mail.customerdomain.com.64/29.100.51.198.in-addr.arpa.. Add trailing dot. |
| Subnet delimiter mismatch | ISP configured 64-29; customer configured 64/29 in named.conf. |
Align customer zone name exactly with the target FQDN returned by the upstream CNAME record. |
| Lame delegation | ISP NS records point to old/decommissioned customer hostnames or IPs. | Contact ISP NOC to update the parent NS records inside the /24 master file. |
Validating Global Resolution
DNS caches can mask configuration errors. If your upstream provider recently corrected an RFC 2317 CNAME or delegation entry, recursive resolvers globally may hold the negative cache entry (governed by the parent SOA minimum TTL) for hours.
To confirm that your reverse DNS configuration resolves cleanly from independent global vantage points without local cache bias, test your IP using the InfoWebStats Reverse DNS Lookup tool. This allows you to verify that external mail servers, security scanners, and remote resolvers traverse the CNAME delegation chain successfully and receive the authoritative PTR record.