HOWTO Delegate Reverse Subnet Maps

This HOWTO configures delegated reverse subnet maps as defined in RFC 2317 to support classless routing. 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).

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.