HOWTO Delegate Reverse Subnet Maps
This HOWTO configures delegated reverse subnet maps as defined in RFC 2317 to support classless routing. The technique defined in the RFC is attributed to Glen A. Herrmannsfeldt. There is a longer explanation of reverse mapping which covers the same topic.
Delegated reverse mapping requires the support or participation of your ISP or the Authority that assigned the static IP address range.
Scenario: Assume you have an allocated subnet of 32 addresses in the range 192.168.23.64 - 192.168.23.95 from your ISP or other Authority. Delegations can only be made once and the delegation unit in this case is the 23.168.192.IN-ADDR.ARPA domain - which covers more than the IP range allocated. The challenge is to split the range without breaking the single delegation rule. This is done by essentially expanding - using a legitimate 'trick' - the existing DNS namespace as described below. Without using this technique there are only two options: the ISP is wholly responsible for reverse-mapping (which is very common); the user reverse-maps using a local file covering 23.168.192.IN-ADDR.ARPA which has the negative consequence that addresses not owned by the user (192.168.23.0 - 192.168.23.63 and 192.168.23.96 - 192.168.23.255) are essentially blind (because the local reverse map zone file 'sinks' the entire delegation for 23.168.192.IN-ADDR.ARPA).
Note: RFC 2317 uses the CNAME RR to implement the solution as shown in the following zone file fragments. For reverse delegations of => /24 (for example /24 or /26 - essentially a sub Class C block) the CNAME solution is the most efficient and understandable. For reverse map delegations of < /24 (for example /20 or /18) the DNAME RR may also be used to provide the same functionality while creating a significantly smaller and more flexible configuration.
ISP or Delegation Authority Zone File
The following fragment shows the 192.168.23.64/27 subnet as a fragment of a reverse map zone file located at the ISP or other Authority that assigned the subnet:
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.isp.com. root.isp.com. (
2003080800 ; serial number
2h ; refresh
15m ; update retry
2w ; expiry
3h ; nx = nxdomain ttl
)
IN NS ns1.isp.com.
IN NS ns2.isp.com.
; definition of other IP address 0 - 63
....
; definition of our target 192.168.23.64/27 subnet
; name servers for subnet reverse map
64/27 IN NS ns1.example.com.
64/27 IN NS ns2.example.com.
; IPs addresses in the subnet - all need to be defined
; except 64 and 95 since they are the subnets
; broadcast and multicast addresses not hosts/nodes
65 IN CNAME 65.64/27.23.168.192.IN-ADDR.ARPA. ;qualified
66 IN CNAME 66.64/27 ;unqualified name
67 IN CNAME 67.64/27
....
93 IN CNAME 93.64/27
94 IN CNAME 94.64/27
; end of 192.168.23.64/27 subnet
....
; other subnet definitions
; which may be delegated or local
....
; local IP definitions
; CNAME and PTR RRs may be mixed in the same file
129 IN PTR bill.isp.com.
....
The 64/27 construct is an artificial (but legitimate) way of constructing the additional space to allow delegation. This is not technically a domain name (in the sense that it is not registered) and therefore can use '/' (which is not allowed in a domain name by RFCs 821, 952, and 1123 but is permitted under the more liberal rules of RFC 2181) but it could be replaced with, say, '-' giving 64-27 (which is allowed by RFCs 821, 952 and 1123) if that makes you more comfortable knowing you are entirely within all possible rules. Delegated reverse maps are one place where the BIND specific $GENERATE directive may be used to avoid needless (and boring) repetition.
Note: Only the zone file is changed at the ISP/Delegation Authority. No change is required to the named.conf file. Explanation: If, say, the CNAME 65.64/27.23.168.192.IN-ADDR.ARPA is resolved during the search of the zone file 23.168.192.IN-ADDR.ARPA, DNS software will, as normal, attempt to follow the CNAME since the domain name part is within the current zone. In this case the NS RRs for 64/27 are encountered resulting in a referral to the name servers ns1.example.com and ns2.example.com being returned.
Customer/User Zone File
The zone file at the DNS serving the Reverse Map (ns1.example.com in the above example) looks like this:
$ORIGIN 64/27.23.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.example.com. root.example.com. (
2003080800 ; serial number
2h ; refresh
15m ; update retry
2w ; expiry
3h ; nx = nxdomain ttl
)
IN NS ns1.example.com.
IN NS ns2.example.com.
; IPs addresses in the subnet - all need to be defined
; except 64 and 95 since they are the subnets
; broadcast and multicast addresses not hosts/nodes
65 IN PTR fred.example.com. ;qualified
66 IN PTR joe.example.com.
67 IN PTR bill.example.com.
....
93 IN PTR web.example.com.
94 IN PTR ftp.example.com.
; end of 192.168.23.64/27 subnet
Now you have to change your reverse map zone names in the named.conf file at the Customer/User DNS to reflect the above change. The following examples shows the reverse map declaration before and after the change to reflect the configuration above:
// before change the reverse map zone declaration would look
// something like this
zone "23.168.192.in-addr.arpa" in{
type master;
file "192.168.23.rev";
};
Change to reflect the delegated zone name.
// after change the reverse map zone declaration would look
// something like this
zone "64/27.23.168.192.in-addr.arpa" in{
type master;
file "192.168.23.rev";
};
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
