Date: Tue, 08 Aug 1995 19:34:21 -0400 From: Rob Austein To: bigz@isi.edu Subject: How To Name Every Particle In The Universe Using Existing DNS Software Message-Id: <9508081934.aa03473@rurha-pente.epilogue.com> Well gosh darn, this mailing list is back from the dead. The following is a short paper I wrote a while back on the tension between globally-unique names and user-friendly names, and on a halfway-serious proposal of how to solve the problem. Since some of the recent messages on this list seem to be recapitulating the line of thought I had at the time, it seemed like it might be time to resurrect this idea. No, I won't be offended if you laugh, I expect most people to find this idea weird at the very least. --Rob ================================================================ How To Name Every Particle In The Universe Using Existing DNS Software Rob Austein, 3 November 1993 Note This document is a preliminary think-piece. If enough people agree that this idea is worth pursuing, I'll submit it as an Internet-Draft. Please do not redistribute this document (yet). Premise As the Internet continues to grow, it will become more and more difficult to support names that are both meaningful to humans and globally unique. This applies whether we continue to use the DNS as currently structured, move all the hosts out of the big first-level zones (.COM, .EDU, etcetera), or move to a new naming system like X.500. The fundamental problem with "big zones" is not difficulties in the zone transfer protocol or the database implementation; we know how to fix these and are working on doing so. The hard problem is saturation of the namespace: the more hosts are registered, the fewer "good" names are left for newcomers to register. Thus the "human readable" informational content of the DNS names will become less and less meaningful, until we are left with names that are essentially just unique identifiers. I believe that I know how to solve this problem. The change could be implemented with no modifications to the existing DNS software. The change does, however, require a fundamental change in the way people think about DNS names. The Fundamental Observation The DNS naming scheme itself is quite flexible and robust, and, with relatively minor enhancements, should scale well to provide a naming system for many years. The problem arises because we are currently overloading two very different functions onto the same portion of the namespace: uniqueness, and human-friendliness. As people have been pointing out for some time, we are gradually losing the human-friendliness features in order to maintain the uniqueness. There's almost certainly no way to avoid this as long as these functions are overloaded. So we should consider whether there is a way to decouple the uniqueness property of DNS names from the human readable property. Another way of saying this is, let's consider a world where unique names don't need to be user-friendly, user-friendly names don't need to be unique, and we can translate between the two. The Solution I suggest that the way to decouple these functions is to abolish the single global root of the DNS tree. In its place, picture a world in which every "site" (community which wished to share the exact same human-readable namespace) runs its own root zone, and all root zones contain delegations to the globally unique portion of the DNS database. Thus, the DNS database is no longer a strict tree, but rather a collection of trees with joins in certain well-known places. This model is roughly equivilent to the way that shared network filesystems work on unix. Every host runs its own root directory, and mounts the shared portions of the filesystem in lower parts of the tree. It is up to each system administrator to decide which parts of the host's filesystem are strictly local and which parts are shared with the larger community. Adding Local Naming With the root of the DNS tree under local (site) control, the problem of assigning human-readable hostname becomes much simpler, because the local administrator can use almost any naming scheme desired (restrictions detailed below), and the names will be short. In other words, the "good" names are available again. If a site becomes so large that it encounters the same scaling problem, it's probably time for it to split into multiple sites, since the site is probably approaching the size of the current Internet. Global Aspects Of The DNS That We'd Want To Keep We still want the globaly unique host identifier functions of the DNS, so we'd still want to keep the global naming tree in which each host is registered. But we no longer insist that the names be human-friendly. In the extreme case, we could simply use ASN.1 Object Identifiers as unique DNS names, spelling them backwards per the usual DNS conventions for mapping big-endian hierarchies. As a practical matter, we'd probably want to keep the current DNS name tree as part of the globally unique tree, to provide a transition period during which the Internet community could upgrade to the new hierarchy. The decision about exactly which portions of the tree should be part of the global namespace, while important from an operational and political standpoint, does not really change the architecture. Mapping Between The Unique Tree and the Readable Tree Within a site the human readable names are unique, but as soon as a DNS name leaves a site it would need to be converted to a globally unique name so that it will be useful to foreign users. So each site that will ever communicate with the outside world needs to have a globally unique name and there needs to be an automatic mapping between readable names and unique names. Here's the proposed mechanism, justification and discussion follows: o To map from a readable name to a unique name, use a CNAME RR. o To map from a unique name to a readable name, use a PTR RR (or a new RR type with identical syntax). The intent is to make the translation from the readable name to the unique name completely automatic. Since DNS-aware software (particularly mail software) is already supposed to translate to cannonical names by following CNAME RRs, any installed software that complies with current standards should continue to work correctly. The translation back from a unique name to a readable name is a little more complicated, because software can't just discard the unique name after obtaining the translation. We want to do the translation for the sake of the poor human, but want to keep the unique name too for the sake of the poor software. Further, sometimes even the human will need the unique name, or at least information derived from the unique name (such as "you may think you recognize that readable hostname, but it's not the one you think it is"). Thus, the translation from the unique name to the readable name should not be automatic, and a PTR RR (or work-alike) is an appropriate mapping representation. Note that this all implies that all of the current DNS information associated with a host would go into the unique portion of the tree, and the readable portion of the tree would just contain DNS structuring RRs and CNAME RRs. Also note that while none of this requires any change to installed DNS software, it does require (or at least strongly encourage) an upgrade to application software to display both unique and readable hostnames. On most systems this would probably really be a change to a single existing module that sits somewhere near the API that applications use to talk to the DNS. Sharing Readable Names Between Sites There may be cases where two (or more) sites wish to share some portion of their "readable" namespaces. This can be done with the "search list" mechanism described in the DNS specifications and implemented by many DNS resovlvers (including BIND 4.9.2). Since site administrators have nearly total control over the structure of the "readable" portion of their trees, they should have more than enough flexibility to structure their trees in such a way as to allow easy searching and sharing. Summary I have described a reorganization of the DNS hierarchy that would allow us to solve a serious and growing scaling problem in the Internet. The transition can be done without a flag day and without breaking the installed software base. The reorganization would also make it easier to decentralize the adminstrative burden that the DNS currently imposes on the maintainers of the top-level zones, and would remove most of the political aspects of the naming system. I expect that the changes I've suggested will meet an immediate reaction of fear and loathing. That's ok, but I ask that you consider the proposal seriously as an extremely rough draft of a long-term solution to the namespace scaling problem. Acknowledgements The ideas here come from a number of people, none of whom are responsible for what I did with their ideas. Particular thanks to John Romkey, who first convinced me that the existing DNS as a human-readable naming system was doomed, and Dave Bridgham, who put up with a lot of ranting on this subject while I was working out the ideas in this note. ================================================================