Internet and e-mail policy and practice
including Notes on Internet E-mail


Click the comments link on any story to see comments or add your own.

Subscribe to this blog

RSS feed

Home :: Internet

08 Sep 2011

The design of the Domain Name System (Part III) - Name structure and delegation Internet

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 organization wanted to delegate names starting with A to one group, and names starting with B to another group, so they delegate,, and to the first group, and,, and 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 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,,,,, and Then the organization can delegate to the first group and 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

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 through

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 through, create these CNAME aliases: CNAME
 ... CNAME

Then do one zone delegation of 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 are different, uk and are the same, while the third level 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,, and are all run by CIRA, but 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 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.

  posted at: 10:13 :: permanent link to this entry :: 0 comments
Stable link is


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

It turns out you don’t need a license to hunt for spam.
62 days ago

A keen grasp of the obvious
Italian Apple Cake
620 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed

© 2005-2024 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.