Home / Blogs

The Design of the Domain Name System, Part III - Name Structure and Delegation

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

Then do one zone delegation of 64- 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.

By John Levine, Author, Consultant & Speaker

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC


Sponsored byVerisign

Domain Names

Sponsored byVerisign