Much Fuss About the DNS (and IP)
The domain names (as in www.frankston.com) seem to be a scarce resource as companies try to secure their own ".com" names. There are also too few Internet addresses to go around. Alas, the "crisis" is due to a lack of understanding of the role of the domain names. There are more appropriate mechanisms already available.
12-Jul-1999Version 2: 2023-05-28 17:09:26

Bob Frankston and David Reed


Once you have read this, you should read the Safe Haven Proposal, written for ICANN, urging separating the semantics of DNS names from the basic mechanisms of the DNS.

Executive Summary

This summary assumes you have a general familiarity with Domain Name System (DNS) and with IP addressing issues.

Briefly:

  • The DNS is not a fundamental service on the IP infrastructure. It is one of a number of services for looking up names to find IP addresses and other information.
  • The DNS names are like phone numbers. Just as with phone numbers (and email addresses) one relies on a directory service to look up names. We are used to a small network with a small number of corporate names. But this is an accident. Names like John Smith, or Main Street Pizza require a directory service.
  • There are already many directory services available and current browsers facilitate looking up names instead of typing in URLs. It is straightforward to make the directory lookup readily available in all places where one can type a DNS name (or a URL)  and by using a personal address book (or a favorites list) to save the results. A readily available directory is far better than guessing a URL.
  • Given an effective directory, there is no need for domain names to be visible or even special. Having an entry under a top level directory like ".com" is no longer necessary and is no longer valuable.
  • The use of Version 4 IP addresses represents another artificial scarcity. Better to spend the resources deploy version 6 than wasting valuable international policy thinking on a nonproblem.

The DNS and IPV4 scarcities are artificial issues born of ignorance. The solution is in understanding what they are and what mechanisms we do need.

Introduction

The Domain Name System (DNS) and the IP address assignments have become the focus of urgent public policy debate due to a perceived scarcity of available names. But the crisis is artificial born of misunderstanding the nature and role of the DNS and the nature of the Internet itself.

It isn't surprising that those unfamiliar with the history of the Internet and its underlying technology would confuse the DNS with a system of trademarkable names. It is obvious that the DNS doesn't work in this rule. It is unfortunate that those who seek to solve this problem tend to exacerbate it by adding rules and seeing a need for governance of a broken mechanism rather than questioning whether the DNS is the correct mechanism.

Both ICANN (The Internet Corporation for Assigned Names and Numbers) and its opponents (including ICANN Watch) seem to be arguing over how to create mechanisms that can only perpetuate the problems with the DNS.

The purpose of this essay is to explain the role of the DNS and the IP address. We can then present simple solutions that demonstrate that there is no scarce resource to be allocated. The issues associated with the trademarks in international commerce are exacerbated because the Internet facilitates communications. But it is not an Internet issue nor a DNS issue.

The DNS

The DNS was not part of the original Internet. Instead one just assigned an IP (Internet Protocol) address to each computer. With only a small number of stationary computers,  it was easy to give each one its own address.

It soon become obvious that managing and remembering these IP address was a problem. There was also a need to store other information, including how to route email from one host to another. The solution was an application service that could be used to lookup information.

Since the DNS is not part of the underlying infrastructure, the designers were able to create a registry that was independent of the organization of the network itself. In fact, anyone is allowed to create a DNS service and run it on one's own personal computer. To be useful, the DNS system is organized as a global hierarchy so that a name like joe.zxa17.com is valid anywhere. This avoids the problem with local phone numbers that lose their meaning outside of their area codes and country codes. 

7673 by any other name is Rose

A domain name is very much like a phone number. A phone number can be viewed as hierarchical name with the top level being the country code (such as "1" for the United States and "44" for the United Kingdom). In the United States we then have an area code, and exchange, a local number and, often, an extension number. We can write this as +1-617-555-1212x123. Or, to make it look more like a domain name, 123.1212.555.617.1.phones.  Since these are numbers, we resort to a separate directory service to translate a descriptive name into a number.

The DNS is a registry of identifiers that are just like phone numbers. The only difference is in the flexibility of being able to use words and the ability to choose local names. Thus, joe.eedept.school.edu, which is easy to remember. This worked fine in the early days of the Internet, especially when a relatively small number of schools dominated the network.

In fact, the system worked so well that people got in the bad habit of guessing the domain name. Thus MIT is mit.edu and the University of Washington is uw.edu. And Leeds University is leeds.ac.uk. This worked just like a small town which didn't need a phone directory because everyone knew everyone else and you'd just call the operator and ask for Joe.

This naiveté has persisted even as it has become increasingly obvious that the approach simply doesn't scale, any better than depending a dialing 1-800-JaneDoe for finding a particular Jane Doe.

Directory Services

Once we understand that the role of the DNS name is identical to that of a phone number, it becomes obvious that we must introduce a directory service.

The directory service must reflect the full ambiguities and complexities of the real world. We must not confuse the concept of a directory service with mechanisms such as LDAP (a protocol for a particular directory search algorithm). For phone numbers, we have a marketplace of directory services. There are competing phone numbers. Some are just listings, while others have listings by product  or service. One can advertise to gain additional prominence. Industry directories provide another way for companies to find each other.

After looking up a phone number, one would often write it in a personal phone book to avoid having to search again, since finding the phone number may have involved much work such as discovering which of the John Smiths was the one in your college chemistry class.

The same reasoning applies to the DNS. Instead of assuming that smith.com is the John Smith we are looking for, we can search and discover that the correct address is Smith1921z.alum.mit.edu. While we can use computers to facilitate this search, there is no automated solution to finding the right "John Smith", one may have to phone or send email to ask whether this is indeed the right John Smith. The only reason that searching may seem awkward is because we are used to typing in long URLs (The Web Universal Resource Locators) or manually entering email addresses. But guessing a URL from a name only works when there are only a small number of names of well-known companies.

Perhaps the temptation to see the web as simply another broadcasting medium like television makes it seem like a publishing medium for a few large companies. The Web is not a broadcast medium, it is a connectivity medium and we all need web identities. In fact, we already do have email names and accept the need for looking names up in directories. The fact that we type "@" rather than "." is a minor difference. The naming convention is the same. (see a side discussion on email).

Tim Berners-Lee built the World Wide Web using existing tools whenever possible. The URL uses a DNS name to identify host systems.  But it needn't be the only naming convention. One can, for example, use a descriptive name to find any system meeting criteria. Tim didn't expect people to type in URLs. After all, with computers to manage the links there shouldn't be a need. One was supposed to point to a destination to link to it. Given the initial small scale of the web, typing the URL worked well-enough to get the Web started. But, as evidenced by the effort to address DNS issues, it is becoming increasingly problematic.

Form the early days of the web, indexing services and directories have been important and are available from many providers. But they have not been well-integrated into other tools. But recent browsers do provide an automatic search capability for names typed into the address line. Extending this approach to integrate a personal directory (that includes the URL's one has already found) and making the capability available anywhere one can type a URL should eliminate most of the reasons for typing URLs!

URLs are also convenient in printed correspondence and in advertising. But we already accept the use of meaningless phone numbers in the same contexts.  In fact, we can use the phone numbers themselves as identifiers as in 16175551212.phone. Or, we can shorten it to aa78xaz.com while adding reliability by using a technique such as a check code to avoid simple typos. Typing aa87xaz.com by mistake will simply be invalid instead of going to a competitor.

The other place one sees phone numbers is in broadcast or print advertisements. We already know about scrambling to write down a phone number. With the Web we can make it very easy to find both phone numbers and URLs by making them available on the web on pages corresponding to the advertisements. A radio station could just list the advertisers and their contact information for each commercial.

The Next Steps

The directory approach is simple and attractive and reflects current practice, while allowing those who want to offer their own solutions the freedom to do so. How do we make this happen?

A first step is to make the DNS names much more flexible than they are. This has the added benefit of reducing the obsession with .com. Why do so many people and companies feel obliged to pay $75 to Network Solutions when they can simply have a second level name with no fee at all. One $75 for azzzazz.com allows any number of free second level registration.

We can then strongly encourage and support a move to directory services. The World Wide Web (W3) organization can work with the primary browser companies (company?) to create standard ways to add directory services of one's choice. In fact, there are existing frameworks that might be sufficient.

The next challenge is similar to that faced by phone companies as it has become obvious that splitting area codes is not a tenable approach in a world where the phone number has, in fact, become a persistent identifier. The incumbent phone company had the "good" numbers like "212" in New York. New numbers are assigned in "646". This created controversy because the new phone companies felt that their 646 numbers were second-class compared with those that Bell-Atlantic owned. In the same way, companies that have their company name registered as their identifier in .com will enjoy an advantage.

This advantage can be reduced by accelerating the acceptance and primacy of directory services so as to reduce this advantage. In the meantime, rather than trying to reduce the amount of confusion, public policy should favor exacerbating the current situation in order to create the correct perception that such names are not reliable as identifiers. We already see this situation with those looking for information about Presidential candidates for the year 2000 United States election often finding themselves at look-alike bogus sites. A trusted directory provider (?) could take responsibility for directing the user to the official site.

DNS Issues

The focus of this essay is on ICANN and public policy. But we must not lose site of the fact that the DNS itself has serious flaws:

  • IP addresses are frequently reassigned due to network management changes or because many systems lack permanent addresses. This requires immediate updates to reflect these changes. The current DNS often takes days to propagate changes.
  • Services such as mail and file transfer do not have their own DNS entries. Instead, they have fixed port numbers which makes it difficult to manage loads and servers.
  • The mapping of an IP address to a DNS doesn't reflect the ability for systems to have multiple addresses.
  • The DNS doesn't facilitate finding services such as a nearby laser printer with larger paper. Such complex searches require a very different mechanism.

IP Addresses

The other scarce resource is the IP address. It is very unfortunate that a few of the initial designers couldn't imagine that they were creating more than a toy system. To many of us, it was obvious that there would be many more than four billion devices that had to communicate.

The legacy of the 32 bit IP address, or IP Version 4, lives with us today. We must treat the IP address as a scarce resource. This puts pressure on the DNS to respond rapidly as we keep reassigning addresses. The United States has a disproportionate number of the addresses, thus disenfranchising much of the world.

The small V4 address size has also created a legacy of work-arounds such as Network Address Translation. For those using their computers for browsing the web, the problems are not immediately obvious. But the value of the Internet is in providing connectivity from any device to any other device. Systems without addresses are simply disenfranchised.

There, too, there is a simple solution, the IPV6 address. But many argue that it's too late to make any changes. They also note that the existing customers (those who already have their addresses, of course) don't see the need for change. This complacency should be recognized as short-sightedness rather than a reason to ignore the future.

A V6 address can be seen has having two parts - a 64 bit local address and a 64 bit global prefix. This allows for many trillions of systems. We can assign an address to each atom in the universe and have many left over.

The solution is to simply start using V6 addresses in the devices. They can talk among each other on their local networks. The existing V4 address can act as a prefix in the V6 address. Thus, the V6 islands can communicate and thus are not really islands. For a few common services, such as web access, bridging between V4 and V6 is relatively simple. Over time, all but the most popular services will be able to assume a V6 world. Again, to use the phone analogy, it took 40 years, but we now have many services that assume one has a touch-tone phone.

Governance?

Much of the debate is abetted by common sense notions. There must be a scarce resource, and there must be a need to govern it. This seems similar to the First Amendment of the United States Constitution guaranteeing free speech. Even after two hundred years, many people see the need for governing the use of speech and the spread of ideas. There must be higher authority who can manage ideas.

The Internet has been wildly successful despite the presence of only limited control. The DNS is not fundamental, it is simply a mechanism for looking up resources. Once the domain name is not kept artificially scarce, all that is left is a technical problem of assuring that the root servers are available and reliable. This is a task better handled by technical committees than lawyers.

With V6, there is no scarcity of IP addresses. The only issue is assuring that one routes messages efficiently from one system to another. Again, just a technical issue.

If there is a role, it is in helping to assure that the Internet does not become hostage to a small number of players controlling the backbone connectivity.  This is the danger in having a transport company like ATT or Deutsch Telecom, being an exclusive (or one of a small number) of local providers. They are in the position to assure much better access to their content and services than to others. Even this is only likely to be a short term advantage.

Any rules should be aimed at helping the Internet grow unfettered. For example, those who transport IP packets shouldn't be able to decide which packets should be allowed and which should. They shouldn't be able to limit connectivity or give preferences to their own services. Ideally the market forces will prevent this. But, if there is a need for governance, it is to limit the ability of the networks.

Conclusion

The Internet is something new and exciting. The danger is in applying our common sense notions of scarcity into this new infrastructure and then creating policies to create scarcity where none exists.

Our focus must be on understanding the nature of the Internet and on assuring that it can continue to be the economic engine it is and not shackled in a naive attempt to do good.

For a better understanding of the nature of the Internet itself, you can read Bob's essay on the IP Infrastructure. David, other readings?

Appendix

Technical Background of the DNS

The DNS is defined in Internet RFCs. RFC1591 is a current reference document. You can also look at the DNS Resources Directory.

In the early days of the Internet, each system was assigned an IP address. With billions of addresses available and only a small number of systems it was easy to assign each system a permanent address. To access a system one could just type the IP address such as 192.55.226.1 (each number representing one byte (8 bits) of the 32 bit address). In order to avoid typing the number, one could maintain tables that mapped names to the addresses. Even today, "hosts" files are common on many systems including Windows.

While the Internet was growing,  Unix systems started to be connected via their own protocol, UUCP (Unix-Unix Copy Protocol). One was able to send mail between systems by specifying a route through intermediate systems. To get mail to Joe on system Pluto via intermediate systems, you would address mail as First!Second!Third!Joe.

The Domain Name System was created as a tool to manage all of this information in a standard and distributed fashion. David, or other pioneer, can you please supply some of the details here?

The DNS provides a mechanism for associating names with information records. One record is the "A" address record that associated a name with an IP address. Another record is the "MX" record which provides routing information for an email address. This is what allows us to write "Joe@Third.com" and have it automatically delivered to First!Second!Third!Joe. Since the DNS is just a registry, it can store the email routing even if the delivery path is via other networks and mechanisms.

Each DNS registers itself within a superior to domain. This allows one to look up domain a in domain b which we write as a.b. In order to find the root servers, each system has a list of root servers. By choosing different root servers, one can use entirely different names. By convention, so that we can exchange DNS names, there is a standard list of roots that support the common naming.

One secret of the Internet has been its ability to evolve from simple designs. The ability to do a quick implementation and update the implementation as one learned from experience has provided the innovative vitality that has made the network what it is. But this doesn't mean that all of the early expedient decisions have aged well. Some, like the 32 address and the DNS design are becoming increasingly problematic.

Those who do not know history, tend to accept the present state of affairs rather than questioning it. The DNS was designed for a simple world where there were few changes to IP addresses and those that did take place were not critical. In a world of personal computers that can be built in a few minutes and get an address that is valid only while they are connected to the network, the DNS cannot provide the necessary dynamics.

Email Names

The @ convention for email adds confusion. Smith0751@aol.com is accepted but a domain name like Smith0751.com is not considered acceptable. But they are essentially the same and should be identical since the @ sign is really a bug in email. For my paper mail, I don't need to register each family member with the post office, but with email, I must register each family member with a provider like aol.com. Email addresses are mailbox identifiers, whereas postal addresses specify people as well as the delivery point. As with email, the post office delivers mail to mailboxes also but, unlike email, leaves the envelope intact so we can do our own distribution to family members or to role names like "head of household".

Translating this into a domain name, then we should have Joe@Smith0751@aol.com. But this isn't a valid syntax. If we didn't have the @ sign we would write this simply as Joe.Smith0751.aol.com.

Email names constitute a set of local names just like any set of subdomain names. We readily accepted the need for a directory to look up email names. Names without the "@" should be no different.

Email addressing is an interesting topic in its own right and its own essay.

CNRP

The IETF is discussing proposals to implement directory systems. The Common Name Resolution Proposal is a step in this direction. It formalizes some of the interface to directories. Network Solution is cooperating in this effort.

This approach doesn't provide the full richness we would want from directory services nor does it assure the availability of a search in all places we might need to type a DNS name or URL. But it is a very positive step towards relegating the current DNS names to their role as obscure identifiers.