mail us  |  mail this page

contact us
training  | 
tech stuff  | 

BIND 9 Support

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.

Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 zone records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

Search

web zytrax.com

Share

Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY
share page via facebook tweet this page

Page

email us Send to a friend feature print this page Display full width page Decrease font size Increase font size

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: May 16 2022.