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, most modern mailing systems use reverse mapping to provide simple, first-cut, authentication using a dual look-up process - IP to name and name to IP. IPv4 reverse mapping is not mandatory though, as indicated by the mail example, it is essential for hosts that send mail, using either a Mail Transfer Agent (MTA) or a Mail User Agent (MUA). In the case of IPv6 reverse-mapping was originally mandatory but as part of the seemingly relentless move to relax the goals of the original specifications (doubtless for good operational reasons) it is no longer a mandatory requirement. It seems to have fallen into the Jolly Useful ™ category.

In order to perform Reverse Mapping using normal recursive and Iterative (non-recursive) queries the DNS designers defined the special (reserved) Domain Name of IN-ADDR.ARPA for IPv4 addresses and IP6.ARPA for IPv6 addresses.

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) which happens to be 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 perfectly legitimate since domain names are case insensitive but the case should be preserved between query and response, so we will continue to use IN-ADDR.ARPA. You may elect to use whatever you wish including IN-addr.Arpa if that is your preference).

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.

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         ; nx = nxdomain ttl
                              )
              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 - FQDNs) in reverse mapped zone files because if we did not our $ORIGIN directive would lead to some strange results. For example, if we wrote an 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.

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         ; nx = nxdomain ttl
                              )
              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
; 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. 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.

Note: Only the zone file is changed at the ISP/Delegation Authority. No change is required to the named.conf file. Reason: If, say, the CNAME 65.64/27.23.168.192.IN-ADDR.ARPA is obtained 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.

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      ; 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

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.

IPv6 addresses are forward-mapped using AAAA RRs and reverse mapped using PTR RRs.

Unlike IPv4, where reverse mapping is frequently not delegated to the end user, IPv6 allows delegated reverse mapping. The end user can therefore be responsible for creation of reverse-mapping zone files using the IP6.ARPA domain for the address range they have been assigned, depending on the policies of the IPv6 address assignor. The IP6.ARPA domain is similar to the IN-ADDR.ARPA domain used for reverse mapping of IPv4 addresses.

Assume the user has been allocated from a RIR (Regional Internet Registry) or ISP a fairly typical IPv6 range:

2001:db8:0::/48

Assume also, that the user has been delegated, by the RIR/ISP, the responsibility for reverse mapping the 80-bit addresses in this range. IPv6 reverse mapping uses the normal principle of reversing the address and placing the result, in the case of IPv6, under the domain IP6.ARPA. The key difference from the IPv4 IN-ADDR.ARPA domain (described previously) is that a nibble is the unit of delegation. A nibble is one of those glorious terms that have survived to enter the jargon. Each byte (or octet) is comprised of 8 bits; a nibble is part of a byte and consists of 4 bits. So a nibble is a small byte! (It might not so glorious for non-native users of English) In the context of reverse mapping, each character in the IPv6 address string constitutes a nibble. To illustrate how this works, we must write each character - with no zero elimination - of the assigned addresses range:

2001:0db8:0000::/48

Each character is reversed and separated with the normal dot notation to give a reverse-map domain name as shown here:

0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA

Now assume, purely for the sake of simplicity, that only 256 active host addresses are used:

2001:db8:0::/8 # 256 hosts
# range 2001:db8:0::0 to 2001:db8:0::FF

Based on this we can construct a zone file to contain the definitions as shown here:

; reverse IPV6 zone file for example.com
$TTL 2d    ; default TTL for zone
$ORIGIN 0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
; Start of Authority RR defining the key characteristics of the zone (domain)
@         IN      SOA   ns1.example.com. hostmaster.example.com. (
                        2010121500 ; sn = serial number
                        12h        ; refresh = refresh
                        15m        ; retry = refresh retry
                        3w         ; expiry = expiry
                        2h         ; nx = nxdomain ttl
                        )
; name server RRs for the domain
          IN      NS      ns1.example.com.
; the second name server is
; external to this zone (domain).
          IN      NS      ns2.example.net.
; PTR RR maps a IPv6 address to a host name

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     ns1.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     mail.example.com.
....
F.F.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0         IN      PTR     fred.example.com.

The individual PTR address labels can become brutally long. The constructed domain name, however, does not have to reflect the address segmentation between the global routing prefix and the end-user part of the address as shown in the preceding example. If we assume that we will only ever have a maximum of 65,535 hosts (uses only the right-most 16 bits of the Interface ID or 2001:db8::/16), then we can move some more of the end-user address into the zone domain name, which is written once, to reduce the address part in each PTR line, which may be written many hundreds of times. Thus the IPv6 address splits in the table below achieve the same result.

Zone Name	PTR Part	Note
0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.	1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0	Uses a split based on the global routing prefix.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.	1.0.0.0	Uses a split based on user convenience to reduce the size of each PTR RR.

The zone file to implement this alternate structure are shown next:

; reverse IPV6 zone file for example.com 
$TTL 2d    ; default TTL for zone
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
; Start of Authority RR defining the key characteristics of the zone (domain)
@         IN      SOA   ns1.example.com. hostmaster.example.com. (
                        2010121500 ; sn = serial number
                        12h        ; refresh = refresh
                        15m        ; retry = refresh retry
                        3w         ; expiry = expiry
                        2h         ; nx =  = nxdomain ttl
                        )
; name server RRs for the domain
          IN      NS      ns1.example.com.
; the second name server is
; external to this zone (domain).
          IN      NS      ns2.example.net.
; PTR RR maps a IPv6 address to the hostnames 

; PTR RR maps a IPv6 address to the hostnames 
1.0.0.0.            IN      PTR     joe.example.com.
2.0.0.0             IN      PTR     www.example.com.
....
F.F.0.0             IN      PTR     fred.example.com.

Note: Any address not defined in either of the above zone files will, as normal, generate an NXDOMAIN (name error) response. In the case of IPv6 reverse-mapping (and forward-mapping) may not be a simple process as discussed in the next section.

3.5 IPv6 Reverse Mapping Coverage Notes

End-user delegation of IPv6 addresses is typically either a /48 (80 bits of user addresses) or a /56 (72 bits of user addresses). In the case of an end-user connection to a DSL or Cable Service Provider any address mapping would typically be handled either in the DSL/Cable modem or further upstream in the Service Provider's network.

In the case of an IPv6 end-user delegation, the normal expectation of IPv6 is that any address that is forward mapped using an AAAA (colloquially a Quad A) RR is also reverse mapped using a PTR RR. Specifically, RFC 1912 (an INFORMATIONAL RFC) says "PTR records must point back to a valid A record" and that administrators should "Make sure your PTR and A records match." For the following reasons this may not be as simple as it sounds when using IPv6:

1. In most cases IPv6 addresses are configured using SLAAC (StateLess Address Auto Configuration) or DHCPv6 and therefore may not be known other than by manual inspection. Both methods may be configured to provide Dynamic DNS (DDNS) updates to the forward and reverse-mapped zones though in the case of very large networks even this can be problematic due to the potentially large number of hosts involved.

2. Some modern OSes (notably the Windows family) can generate essentially random IPv6 addresses for each session to provide some level of end-user/host privacy. These changes can only be mapped using DDNS since they are by nature both dynamic and transient.

This topic is currently the subject of considerable discussion (Dec 2010). It is worth noting however, that as with the equivalent IPv4 addresses, the only current applications which are known to use reverse mapping consistently are mail systems. Thus, steps should be taken to ensure that, at least, these hosts have a valid IPv6 reverse-map.

Note: While it is possible to use a DNS wildcard to at least provide some generic answer to the reverse-mapping problem the equivalent wildcard forward-mapping possibility does not exist. At best it is a kluge, at worst, positively confusing.