In the previous installments, we looked at the overall design of the DNS and the way DNS name matching works.

The DNS gains considerable administrative flexibility from its delegation structure. Each zone cut, the place in the DNS name tree where one set of DNS servers hands off to another, offers the option to delegate the administration of a part of the DNS at the delegation point. But for the delegation to work well, the delegation structure has to match the name structure.

In particular, a zone cut can only happen between name components, not within them. Assume, for example, the example.com organization wanted to delegate names starting with A to one group, and names starting with B to another group, so they delegate able.example.com, acme.example.com, and adept.example.com to the first group, and baker.example.com, beaver.example.com, and bingo.example.com to the second group.

The DNS doesn’t make that easy, since all of those names are part of the same zone. It would be possible to handle it by custom programming in the provisioning system that manages the example.com zone to manage who can update what names, but it would be a lot easier (from a DNS point of view) to add an extra name level and change the names to able.a.example.com, acme.a.example.com, adept.a.example.com, baker.b.example.com, beaver.b.example.com, and bingo.b.example.com. Then the organization can delegate a.example.com to the first group and b.example.com to the second group, and let them each manage its own zone. This assumes, of course, that it’s acceptable for the applications to use the names with the extra components.

The reverse DNS (rDNS) for IPv4, which allows you to look up a domain name corresponding to an IP address, is the part of the DNS where this problem has occurred most often. Originally, blocks of IP address space were allocated on 8, 16, and 24 bit boundaries. The structure of the rDNS matches these boundaries since it uses a name component for each eight-bit octet of the address. That is, if an organization were allocated the IP address range 12.34.xx.xx, they’d also be delegated the rDNS for 34.12.in-addr.arpa.

As soon as CIDR came along, allowing IP address space allocation at arbitrary bit boundaries, rDNS name delegation became a mess. For ranges larger than /24, delegation is straightforward but tedious. For a /22, the address space holder is separately delegated each of the four /24’s in the /22, e.g., for 12.34.56/22 the holder would get the rDNS for 12.34.56.x, 12.34.57.x, 12.34.58.x, and 12.34.59.x, which are 56.34.12.in-addr.arpa through 59.34.12.in-addr.arpa.

But there’s no practical way to delegate the rDNS for ranges smaller than a /24 using the normal DNS delegation technique. (In theory one could add a zone cut for each individual rDNS name, making each its own zone, but that would be hundreds of tiny zones, something that DNS servers don’t handle well.) Since the names in the rDNS happen to be known in advance, one per IP address, and the number of names in a /24 is only 256, people have kludged around it with groups of CNAMEs, one per allocated address, aliased to names with an extra component to allow normal DNS delegation to work. For example, if someone were allocated the /27 range 12.34.56.64 through 12.34.56.95, create these CNAME aliases:

64.56.34.12.in-addr.arpa CNAME 64.64-95.56.34.12.in-addr.arpa
...
95.56.34.12.in-addr.arpa CNAME 95.64-95.56.34.12.in-addr.arpa

Then do one zone delegation of 64-95.56.34.12.in-addr.arpa. This hack was described in RFC 2137 in 1998, so it’s well established, but it’s still pretty ugly.

IPv6 avoided this particular problem by noting that the smallest plausible allocation boundaries for the huge IPv6 addresses are four-bit groups, and making IPv6 rDNS names have a separate component for each four-bit nibble, so it’s always possible to make a zone cut that matches an IP space allocation. The moral here is to think hard about what you might want delegate in the future when designing your name space.

Conversely, it is also possible to over-decompose DNS names. DNSBLs use the same multi-component name structure as rDNS, but gain little benefit from it other than the range wildcards discussed above. Since each DNSBL is invariably managed by a single organization, in the common case that DNSBLs are served using DNS servers that don’t use wildcards, there’s no benefit to decomposing the name into multiple components. It would work just as well to use names like 127-0-0-2.dnsbl.example, or for IPv6, a 32 character hex number. like 200104701f07112600005370616d6d79.dnsbl.example.

Applications should not assume that any particular name boundary is a delegation point, in particular, that the boundary between a top-level and second-level domain is one. Different domains have different policies, and they are under no obligation to tell you what those policies are. While the management of com and google.com are different, uk and co.uk are the same, while the third level google.co.uk is someone else. It’s also unwise to assume that if a TLD has delegated some names at the second or third level, that all of their delegations are at the same level. For example, ca, qc.ca, and montreal.qc.ca are all run by CIRA, but google.ca is not.

In the cases above, there’s a zone cut at the place where the management changes, but zone cuts do not necessarily represent administrative boundaries either. In many cases a single organization will divide up its own namespace into multiple zones for its own administrative convenience.

There are places like publicsuffix.org that try to keep lists of delegation points for TLDs, but they are only as accurate as the data people contribute to them, which is of highly variable completeness.

In the next installment, we’ll look at the global consistency of DNS data, such as it is.