On the delegating server, define the zone "3.2.1.in-addr.arpa":
$TTL 86400
@ IN SOA ISP.server.com. hostmaster.ISP.server.com. (
2010070900 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns1.ISP.server.com.
IN NS ns2.ISP.server.com.
0/28 IN NS ns1.CUSTOMER.server.com.
0/28 IN NS ns2.CUSTOMER.server.com.
$GENERATE 0-15 $ CNAME $.0/28.3.2.1.in-addr.arpa.
On the other server, define the zone "0/28.3.2.1.in-addr.arpa":
$TTL 86400
@ IN SOA CUSTOMER.server.com. hostmaster.CUSTOMER.server.com. (
2010070900 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS ns1.CUSTOMER.server.com.
IN NS ns2.CUSTOMER.server.com.
11 IN PTR name11.CUSTOMER.server.com.
12 IN PTR name12.CUSTOMER.server.com.
13 IN PTR name13.CUSTOMER.server.com.
Understand that the name "0/28" in this example means nothing to BIND or any DNS tool. It is used in this example to help you remember it is a /28 subnet beginning at 0 but make no mistake; the name is not parsed or interpreted as anything else than a name. As long as the ISP and CUSTOMER in this example agree on a unique name within 3.2.1.in-addr.arpa, that name could be "0-28", "0-15", "CUSTOMER" or "Magic".
Note that the 'dig -x' convenience option does not use the recommended algorithm for resolving reverse addresses and therefore cannot be used with subdelegated reverse zones. This is a known problem. Using dig to manually look up .in-addr.arpa records (without -x) works as expected.
See this discussion for more details:
http://www.webservertalk.com/archive69-2007-1-1776197.htmlAnd here is the original RFC:
http://www.faqs.org/rfcs/rfc2317.html