Home / Blogs

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

Don't miss a thing – sign up for CircleID Weekly Wrap newsletter delivered to your inbox once a week.
John Levine

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. More blog posts from John Levine can also be read here.

Related topics: DNS



To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Sponsored Topics

Promoted Posts

Now Is the Time for .eco

.eco launches globally at 16:00 UTC on April 25, 2017, when domains will be available on a first-come, first-serve basis. .eco is for businesses, non-profits and people committed to positive change for the planet. See list of registrars offering .eco more»

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Don't Gamble With Your DNS

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Dyn Partners with the Internet Systems Consortium to Host Global F-Root Nameservers

Is Your TLD Threat Mitigation Strategy up to Scratch?

Domain Management Handbook from MarkMonitor

What Holds Firms Back from Choosing Cloud-Based External DNS?

Computerworld Names Afilias' Ram Mohan a Premier 100 Technology Leader

Protect Your Privacy - Opt Out of Public DNS Data Collection

Measuring DNS Performance for the User Experience

Introducing Verisign Public DNS: A Free Recursive DNS Service That Respects Your Privacy

Internet Grows to 296 Million Domain Names in Q2 2015

Protect Your Network From BYOD Malware Threats With The Verisign DNS Firewall

Introducing the Verisign DNS Firewall

Verisign Named to the Online Trust Alliance's 2015 Honor Roll

3 Key Steps for SMBs to Protect Their Website and Critical Internet Services

Key Considerations for Selecting a Managed DNS Provider