3. DNS Reverse Mapping

3.1 Reverse Mapping Overview

A normal DNS query would be of the form 'what is the IP of host=www in domain=mydomain.com'. There are times however when we want to be able to find out the name of the host whose IP address = x.x.x.x. Sometimes this is required for diagnostic purposes more frequently these days it is used for security purposes to trace a hacker or spammer, indeed many modern mailing systems use reverse mapping to provide simple authentication using dual look-up, IP to name and name to IP.

In order to perform Reverse Mapping and to support normal recursive and Iterative (non-recursive) queries the DNS designers defined a special (reserved) Domain Name called IN-ADDR.ARPA. This domain allows for all supported Internet IPv4 addresses (and now IPv6).

up icon

3.2 IN-ADDR.ARPA Reverse Mapping Domain

Reverse Mapping looks horribly complicated. It is not. As with all things when we understand what is being done and why - all becomes as clear as mud!

We defined the normal domain name structure as a tree starting from the root. We write a normal domain name LEFT to RIGHT but the hierarchical structure is RIGHT to LEFT.

domain name = www.example.com
highest node in tree is = .com
next (lower) = .example
next (lower) = www

An IPv4 address is written as:

192.168.23.17

This IPv4 address defines a host = 17 in a Class C address range (192.168.23.x). In this case the most important part (the highest node) is on the LEFT (192) not the RIGHT. This is a tad awkward and would make it impossible to construct a sensible tree structure that could be searched in a single lifetime.

The solution is to reverse the order of the address and place the result under the special domain IN-ADDR.ARPA (you will see this also written as in-addr.arpa which is OK since domains are case insensitive but the case should be preserved so we will use IN-ADDR.ARPA).

Finally the last part of the IPv4 Address (17) is the host address and hosts, from our previous reading, are typically defined inside a zone file so we will ignore it and only use the Class C address base. The result of our manipulations are:

IP address =192.168.23.17
Class C base = 192.168.23 ; omits the host address = 17
Reversed Class C base = 23.168.192
Added to IN-ADDR.ARPA domain = 23.168.192.IN-ADDR.ARPA

This is show in figure 3.0 below.

arpa organization

Figure 3.0 IN-ADDR.ARPA Reverse Mapping

Finally we construct a zone file to describe all the hosts (nodes) in the Reverse Mapped zone using PTR Records. The resulting file will look something like this:

$TTL 2d  # 172800 seconds
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@             IN      SOA   ns1.example.com. hostmaster.example.com. (
                              2003080800 ; serial number
                              3h         ; refresh
                              15m        ; update retry
                              3w         ; expiry
                              3h         ; minimum
                              )
              IN      NS      ns1.example.com.
              IN      NS      ns2.example.com.
1             IN      PTR     www.example.com. ; qualified name
2             IN      PTR     joe.example.com.
.....
17            IN      PTR     bill.example.com.
.....
74            IN      PTR     fred.example.com.
.... 

We must use qualified names ending with a dot (in fact they are Fully Qualified Domain Names FQDN) in reverse mapped zone files because if we did not our $ORIGIN directive would lead to some strange results. For example if we wrote and unqualified name such as:

74             IN      PTR fred

Using the $ORIGIN substitution rule the above would expand to fred.23.168.192.IN-ADDR.ARPA. which is probably not what we intended.

up icon

3.3 Reverse Map Delegation

Classless Reverse Map Delegation is defined by RFC 2317 which has Best Current Practice status and should be regarded as a definitive reference. Classless routing allows allocation of sub-nets on non-octet boundaries, that is, less that 256 addresses from a Class C address may be allocated and routed. The technique defined in the RFC is attributed to Glen A. Herrmannsfeldt.

Normal domain name mapping as we have seen maps the domain name to an IP address. This process is independent of the ISP or other authority that allocated the IP name space. If the addresses were to change then the owner of the domain that maps these addresses would be able to make the necessary changes directly with either the relevant registrar i.e. change the IP address of DNS's for the domain or change the zone file(s) that describe the domain.

The rule is that entities can be delegated only once in the domain name tree this includes IN-ADDR.ARPA. When a Class C subnet is assigned by an ISP or other authority, for example, 192.168.23.64/27 (a 32 IP address subnet) the responsibility for reverse mapping for the whole Class C address has already been assigned to the ISP or Authority. If you want to change the host names in the assigned subnet they must be notified to the authority for that Class C address. Generally this is unacceptable since such requests may encounter indifference, cost or questions. It is most desirable that responsibility for reverse mapping be delegated when the IP address subnet is assigned.

The technique defined in RFC 2317 provides for such delegation to take place using CNAME Resource Records (rather than the more normal PTR Resource Records) in an expanded IN-ADDR.ARPA name space.

The following fragment shows our 192.168.23.64/27 subnet as a fragment of the reverse mapping zone file located at the ISP or other Authority that assigned the subnet:

$TTL 2d # 172800 seconds
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@            IN  SOA   ns1.isp.com. hostmaster.isp.com. (
                              2003080800 ; serial number
                              3h         ; refresh
                              15m        ; update retry
                              3w         ; expiry
                              3h      ; minimum
                              )
              IN  NS      ns1.isp.com.
              IN  NS      ns2.isp.com.
; definition of other IP address 0 - 31
....

; 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

The 64/27 construct is an artificial (but legitimate) way of constructing the additional space to allow delegation. Prior to RFC 2181 '/' was not a legal character for a domain name or label so an alternate construct using '-' could be used instead, for example:

64-27         IN  NS  ns1.example.com.

The zone file at the DNS serving the Reverse Map (ns1.example.com in the above example) looks like this:

$TTL 2d # 172800
$ORIGIN 64/27.23.168.192.IN-ADDR.ARPA.
@            IN  SOA   ns1.example.com. hostmaster.example.com. (
                              2003080800 ; serial number
                              3h         ; refresh
                              15m        ; update retry
                              3w         ; expiry
                              3h      ; minimum
                              )
              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

If the alternate construct using '-' is used the $ORIGIN directive above would look as shown below:

$ORIGIN 64-27.23.168.192.IN-ADDR.ARPA.

Now you have to change your reverse map zone names in the named.conf file 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";
};

The above - normal - reverse map declaration resolves reverse lookups for 192.168.23.x locally and without the need for access to any other zone or DNS.

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{
// or zone "64-27.23.168.192.in-addr.arpa in {
  type master;
  file "192.169.23.rev";
};

The above configuration will only resolve by querying the master zone for 23.168.192.IN-ADDR.ARPA and following down the delegation back to itself. If changes are not made at the ISP or issuing Authority or have not yet propagated then this configuration will generate 'nslookup' and 'dig' errors.

up icon

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 dns 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 rfc's
change log