One of the most common uses of DNS is getting an IP number attached to a domain name (forward lookups), but there is a system for doing the reverse, getting a domain name from an IP number (reverse lookups), too. Reverse mapping for example is used by mail servers for tracking spammers by doing first a reverse lookup for the sender’s IP number, and then a forward lookup for the returned domain name, or for diagnostic purposes, such as listing the active internet connections in nslookup.

Reverse lookups are actually quite simple: we do a PTR-type query for a special domain name composed from the IP number. If the IP number is a.b.c.d, we do a PTR-lookup for d.c.b.a.in-addr.arpa..

For example, say we’d want to find the domain for , we’d do a query for the .in-addr.arpa. domain. This might return something like the following:

.in-addr.arpa. 2h PTR vhost.sourceforge.net.

indicating that vhost.sourceforge.net. is a domain name for the IP number.

For IPv6, we have a similar situation in the ip6.int tree, except we get very long domain names, because every character in the IPv6 address gets its own DNS label, and short notations are not supported. For example, the IPv6 number 1aef:a2::dead:beef, is actually, in full:

1aef:00ae:0000:0000:0000:0000:dead:beef

so its reverse-mapping domain name becomes:

f.e.e.b.d.a.e.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.a.0.0.f.e.a.1.ip6.int.

Just like for IPv6 forward mapping (see Using DNS for naming hosts), there is an alternate way of reverse-mapping as well, by means of the ipv6.arpa. domain name and DNAME records. Like the A6 record though, this method is marked experimental and it is not supported by Posadis.

Because especially IPv6 reverse-mapping domains can be bitches to type, Posadis introduces a short syntax for them: a dot followed by the address. For example, in all Posadis programs, .in-addr.arpa. is the same as ., and

f.e.e.b.d.a.e.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.a.0.0.f.e.a.1.ip6.int.

is also known as .1aef:a2::dead:beef. Take your pick. If you need a reverse-mapping zone name, such as 250.35.66.in-addr.arpa., use ..*, or just .66.35.25.

You may know that IP addresses have a kind of hierarchy in them. For example, all IP numbers a.b.c.d with the same value for a are in the same A-class network, and all IP numbers with the same value for a and b are in the same B-class network. From this, delegation of authority in in-addr.arpa. follows quite naturally.

Unfortunately though, sometimes networks are also split within one label, for example, the .0/25 network refers to IP numbers .0 through (classless delegation). So how do you delegate authority here?

Well, there is no system for this, but RFC 2317 suggest setting up CNAMEs for all domain names pointing to delegated subdomains. Say we want to delegate .0/25 to one server, and /25 to another, we’d make the following zone:

0.160.35.66.in-addr.arpa.    CNAME  0.0/25.160.35.66.in-addr.arpa.
1.160.35.66.in-addr.arpa.    CNAME  1.0/25.160.35.66.in-addr.arpa.
(...)
.in-addr.arpa.  CNAME  127.0/25.160.35.66.in-addr.arpa.
.in-addr.arpa.  CNAME  128.128/25.160.35.66.in-addr.arpa.
(...)
.in-addr.arpa.  CNAME  255.128/25.160.35.66.in-addr.arpa.

This way, we can let others control the 0/25.160.35.66.in-addr.arpa. and 128/25.160.35.66.in-addr.arpa. zones for their own IP number. Of course, this approach is only reasonable for /24 or higher classless delegations: imagine managing a /17 delegation: you’d need a zone with 2^15 such CNAME records…1)

If you run an internet domain, you probably don’t want to do reverse mapping: your ISP has probably already done that for you, and you should contact them if you want your reverse-mapping domain pointing somewhere else. Only if you have a complete C-class network or something like that hooked up to the internet you might consider having authority for the reverse mapping delegated to you.

For local networks, you’d want to create two reverse-mapping zones. You always want one to have reverse mapping for localhost, and one for the local IP numbers. The localhost reverse-mapping zone could be as simple as:

$origin 0.0.127.in-addr.arpa.  
@ 2h SOA ns1.localnet. . 1 2h 1h 1d 2h
     NS  ns1.localnet.
1    PTR localhost.

A simple local IP reverse mapping zone could be something like

$origin 168.192.in-addr.arpa.  
@ 2h  SOA ns1.localnet. .  2h 1h 1d 2h
      NS  ns1.localnet.
1.1   PTR ns1.localnet.
2.1   PTR ns2.localnet.
3.1   PTR mail.localnet.
100.1 PTR client100.localnet.
101.1 PTR client101.localnet.

and so forth.

Of note in this context is also the revmap module in Posadis 0.60.* and up. If you want to have working reverse-mapping for your network, and you don’t care much about the details of the reverse mapping, you can use it to have reverse-mapping done automatically for you. Automatically generating PTR records is an approach that many ISPs use.

• WebProNews.com: Basic DNS PTR Records and Why You Care