D. J. Bernstein
Internet publication
djbdns

How to receive a delegation from .in-addr.arpa

If you are in charge of a block of IP addresses, and you want to provide reverse lookups for those IP addresses, you will need a corresponding name in the in-addr.arpa domain. For example, if you are in charge of IP addresses 1.8.7.0 through 1.8.7.255, the domain 7.8.1.in-addr.arpa should be delegated to you.

For concreteness, these instructions assume that the name is 7.8.1.in-addr.arpa, and that you have two computers running DNS servers, the first server on IP address 1.8.7.200 and the second server on IP address 1.8.7.201.

The normal procedure has two steps. First, tell your DNS servers that they should answer questions for 7.8.1.in-addr.arpa, and that they should announce 1.8.7.200 and 1.8.7.201 as the DNS server addresses for 7.8.1.in-addr.arpa: 

     cd /service/tinydns/root
     ./add-ns 7.8.1.in-addr.arpa 1.8.7.200
     ./add-ns 7.8.1.in-addr.arpa 1.8.7.201
     make
Second, tell the parent server administrator to delegate 7.8.1.in-addr.arpa to the server a.ns.7.8.1.in-addr.arpa on IP address 1.8.7.200 and the server b.ns.7.8.1.in-addr.arpa on IP address 1.8.7.201. Fees for this delegation are typically included in the fees for allocating the IP addresses in the first place.

Unfortunately, some parent administrators impose extra restrictions that prevent the normal procedure from working. In particular, ARIN (IP addresses in America) and RIPE (IP addresses in Europe) both insist that all their delegations be glueless. This means that the DNS servers need names outside in-addr.arpa. Gluelessness is bad practice, because it slows down DNS lookups and sometimes destroys DNS lookups, but ARIN and RIPE don't care. (Reported May 2001.)

To deal with ARIN and RIPE, edit /service/tinydns/root/data manually to specify server names in some other domain that you control, let's say x.org: 

     .7.8.1.in-addr.arpa:1.8.7.200:a.reversens.x.org
     .7.8.1.in-addr.arpa:1.8.7.201:b.reversens.x.org
Then tell the parent server administrator to delegate 7.8.1.in-addr.arpa to the server a.reversens.x.org on IP address 1.8.7.200 and the server b.reversens.x.org on IP address 1.8.7.201.

APNIC (IP addresses in Asia and Australia) doesn't insist on glueless delegations, but it does insist that you set up TCP service. (Reported June 2001.)

Reverse delegations for individual IP addresses

If you have are being given a block of fewer than 256 IP addresses, your parent server should delegate each address to you separately.

For example, let's say you want your DNS servers on 1.8.7.200 and 1.8.7.201 to publish computer names for the IP addresses 1.2.3.144 and 1.2.3.145. The administrator of 3.2.1.in-addr.arpa should do 

     cd /service/tinydns/root
     ./add-childns 144.3.2.1.in-addr.arpa 1.8.7.200
     ./add-childns 144.3.2.1.in-addr.arpa 1.8.7.201
     ./add-childns 145.3.2.1.in-addr.arpa 1.8.7.200
     ./add-childns 145.3.2.1.in-addr.arpa 1.8.7.201
     make
and you should do 
     cd /service/tinydns/root
     ./add-ns 144.3.2.1.in-addr.arpa 1.8.7.200
     ./add-ns 144.3.2.1.in-addr.arpa 1.8.7.201
     ./add-ns 145.3.2.1.in-addr.arpa 1.8.7.200
     ./add-ns 145.3.2.1.in-addr.arpa 1.8.7.201
     make
to create the lines 
     .144.3.2.1.in-addr.arpa:1.8.7.200:a
     .144.3.2.1.in-addr.arpa:1.8.7.201:b
     .145.3.2.1.in-addr.arpa:1.8.7.200:a
     .145.3.2.1.in-addr.arpa:1.8.7.201:b
in /service/tinydns/root/data. Then the line 
     =phoenix.elysium.heaven.af.mil:1.2.3.144
will declare that phoenix.elysium.heaven.af.mil has IP address 1.2.3.144 and that the computer name for 1.2.3.144 is phoenix.elysium.heaven.af.mil.

Beware that some in-addr.arpa administrators instead do RFC 2317 ``classless'' reverse delegation, sending your reverse domains through a single delegation: 

     C144.3.2.1.in-addr.arpa:144.144-145.3.2.1.in-addr.arpa
     C145.3.2.1.in-addr.arpa:145.144-145.3.2.1.in-addr.arpa
     &144-145.3.2.1.in-addr.arpa:1.8.7.200:a
     &144-145.3.2.1.in-addr.arpa:1.8.7.201:b
     # or, in BIND master zone-file format:
     # 144.3.2.1.in-addr.arpa. CNAME 144.144-145.3.2.1.in-addr.arpa.
     # 145.3.2.1.in-addr.arpa. CNAME 145.144-145.3.2.1.in-addr.arpa.
     # 144-145.3.2.1.in-addr.arpa. NS a.ns.144-145.3.2.1.in-addr.arpa.
     # 144-145.3.2.1.in-addr.arpa. NS b.ns.144-145.3.2.1.in-addr.arpa.
     # a.ns.144-145.3.2.1.in-addr.arpa. A 1.8.7.200
     # b.ns.144-145.3.2.1.in-addr.arpa. A 1.8.7.201
In this case your data file should contain lines such as 
     .144-145.3.2.1.in-addr.arpa:1.8.7.200:a
     .144-145.3.2.1.in-addr.arpa:1.8.7.201:b
     =phoenix.elysium.heaven.af.mil:1.2.3.144
     ^144.144-145.3.2.1.in-addr.arpa:phoenix.elysium.heaven.af.mil
     =bogey.elysium.heaven.af.mil:1.2.3.145
     ^145.144-145.3.2.1.in-addr.arpa:bogey.elysium.heaven.af.mil
using the same name 144-145.3.2.1.in-addr.arpa selected by the parent administrator. Normally ^ lines are unnecessary, because they are automatically generated by = lines, but classless reverse delegation breaks this feature.

Why would anyone want to use classless reverse delegation? Answer: If you were running BIND, you'd find it only a little bit painful to receive a classless reverse delegation (setting up one zone file), while you'd find it much more painful to receive separate reverse delegations (setting up many zone files).