TL;DR: IPv4 reverse DNS delegations are hard for small network segments, okay?
dn42 is an overlay network running over VPN links which simulates the public internet (both organisationally and functionally) on a much smaller scale. Like the public internet (known as clearnet to dn42), one can register autonomous system numbers, address space and DNS names. Then, you can set up a router and find peers (mostly by asking on the IRC channel) with whom you establish a VPN link over which you can announce your routes using BGP.
It's a great way to learn about internet technologies like BGP and the organisational structure of the public internet. There is also the advantage that if you mess something up, you aren't going to get a big registry like RIPE or ARIN angry at you. The most that will happen is that one of the denizens politely asks you why your network is doing something strange (like passing traffic originating from private address space which isn't routable on dn42 - this has happened to me!).
The address space used internally is the IPv4 private address range 172.20.0.0/16 and the IPv6 Unique Local Address range fd00::/8. Since there isn't exactly a lot of IPv4 address space available (simulated resource depletion, anyone?), most people take allocations much smaller than /24 (this is important!).
dn42 has its own internal hierarchical DNS system (for the top-level domain .dn42) under which one can register domains through the registry. Once you have a domain and a nameserver set up, you can add a nameserver attribute to you IP address ranges so that reverse DNS lookups get delegated to your nameserver.
For IPv4, if you wish to turn a network address into a symbolic name, you ask a nameserver for the PTR record associated with that address. For example, if you want to turn 8.8.4.4 into a domain name, you query for the PTR record of 4.4.8.8.in-addr.arpa and get an answer of google-public-dns-b.google.com. Now, if you have an IPv4 address range of e.g. 192.168.67.0/24, then the root servers will delegate the 67.168.192.in-addr.arpa domain to your nameserver. If you have a bigger address range, there are more delegations i.e. the owner of 192.168.48.0/23 would have 48.168.192.in-addr.arpa and 49.168.192.in-addr.arpa delegated to their nameserver by the root servers. This breaks for smaller address allocations, as the smallest unit of subdivision in IPv4 reverse DNS is the /24 network, so it's impossible to delegate the reverse DNS lookups for a /25 or smaller network.
Turns out there's a way around this. Turns out there's a standardised way around this, by the name of RFC 2317. The solution is to create a domain representing the entire subnetwork (which is delegated to that subnetwork) and then indirect all PTR queries to that domain representing the subnet. That explanation isn't nice to get your head around, so let's have some examples:
You have the IPv4 segment 192.168.204.4/30. You have two usable IP addresses in this range, 192.168.204.5 and 192.168.204.6. In order to set up reverse DNS for your IP addresses, the administrator of the 204.168.192.in-addr.arpa creates a new domain to represent your subnetwork allocation: 4/30.204.168.192.in-addr.arpa. This domain is delegated to your nameserver. Now, the administrator creates CNAME records for each of your IP addresses that fall into their zone which point to subdomains of the domain which represents your subnetwork, i.e. 5.204.168.192.in-addr.arpa points to 5.4/30.204.168.192.in-addr.arpa and 6.204.168.192.in-addr.arpa points to 6.4/30.204.168.192.in-addr.arpa. You then configure PTR records for those two domains on your nameserver pointing to the desired hostnames.
I like djbdns a lot, and I use it everywhere I need a domain server (DNS caching on my laptop, authoritative nameserver for 1.0.168.192.in-addr.xyz, etc). However, some manual intervention is required to make IPv4 reverse DNS properly in the aforementioned case.
I have some IPv4 address space in dn42, and I also have a .dn42 domain name. Normally with djbdns, when you tell it about an IPv4 address, it will publish a matching PTR record.
# This record in a tinydns data file creates an A record and a PTR record
=example.tld:192.168.97.92
# The above line is equivalent to the two following lines
+example.tld:192.168.97.92
^92.97.168.192.in-addr.arpa:example.tld
However, my dn42 allocation is a /29. This means that I have to tell tinydns to accept delegations for the subnetwork domain and then specify all the PTR record manually, a bit like this:
# I have 192.168.97.0/25, so I must accept the appropriate rDNS delegation and point it to my nameserver
.0/25.97.168.192.in-addr.arpa::ns.example.tld
# Now the PTR record
^92.0/25.97.168.192.in-addr.arpa:example.tld
Another case of IPv4 making life hard?