IPv6 reverse DNS only delegates on nibbles

Reverse DNS for IPv6 looks like a formality until a mail server, a monitoring probe or a log correlator does a forward-confirmed lookup and everything stops matching. Then it turns out that the zone you need cannot be delegated from the zone your provider runs, because the prefix you were given is not on a nibble boundary — a rule that has nothing to do with DNS and everything to do with how IPv6 addresses are written.

One label per hex digit

An IPv6 address is 128 bits, written as 32 hex digits. Under ip6.arpa every single hex digit becomes its own DNS label, and the labels appear in reverse order — least significant nibble first, exactly as IPv4 reverses octets under in-addr.arpa.

So 2001:db8::/32, which is eight hex digits, owns a zone whose name is those eight digits reversed:

2001:0db8  ->  2 0 0 1 0 d b 8   ->  reversed:  8 b d 0 1 0 0 2
zone:  8.b.d.0.1.0.0.2.ip6.arpa

The number of labels is the prefix length divided by four, which is the whole constraint:

Why a /33 cannot be delegated

A DNS zone is cut at a label boundary. A label is four bits. So a zone can only begin where the prefix length is a multiple of four: /32, /36, /40, /44, /48, /52, /56, /60, /64.

/33 is not one of them. Thirty-three bits is eight whole labels plus one bit, and that one bit lives inside the ninth label. There is no name for it: the smallest name boundary that contains a /33 is the /32 above it, and the next name boundary below it is the /36. A /33 therefore cannot be handed to a customer as a zone — either the provider keeps the records in their own /32 zone, or the customer is given a /36 or larger.

This is why ISP assignment practice lines up with multiples of four: /48 for a site (12 labels), /56 for a residential connection (14 labels), /64 for a single subnet (16 labels). Those all end on a nibble, and each can become a zone in its own right.

What operators actually do

A /48 zone contains 65,536 /64s. Nobody creates 65,536 zones by hand, so in practice there are three patterns:

• Delegate /56s from the /48. One zone per aggregation block, sixteen /64s each. This is the pattern that scales to a network with more than a handful of sites.
• Generate PTR records from a template. A DNS provider that supports a pattern rule, or a generation script, creates the records under the /48 without creating child zones. Fine for a /64 or two.
• Do nothing, deliberately. Reverse DNS for client and server subnets is optional. It is worth having where something performs a forward-confirmed reverse lookup: mail transfer agents, some monitoring and inventory systems, and anything that logs a name for an address. It is not worth having because a checklist said so.

The one case where it is close to mandatory is outbound mail: many receivers treat a missing or mismatched PTR as a spam signal, and a mail server with no IPv6 PTR is one of the reasons a perfectly configured relay still gets deferred on its AAAA path.

The record itself

A single host inside a /64, taking 2001:db8:abcd:12::25:

; in the zone 2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa
; the host nibbles inside the /64 are 0025, reversed: 5 2 0 0
5.2.0.0  IN  PTR  router25.example.com.

Note what is missing: no ip6.int. That tree was deprecated in favour of ip6.arpa long ago, and records still published under ip6.int are invisible to current resolvers.

Where the calculator helps

The IPv6 subnet calculator prints the reverse zone for whatever prefix you give it, which is the fastest way to confirm that the zone you are about to create is actually delegable — if the prefix length is not a multiple of four, the answer will not line up with anything the parent zone can hold. The prefix splitter does the same job in bulk when you are generating a list of zones for a delegation plan.

The general rule to carry around: the reverse zone of an IPv6 prefix is the prefix written in hex, reversed one digit at a time, under ip6.arpa — and only every fourth prefix length has one at all.