A Host of Problems, Problems with Hosts

At the onset of the 1980s, the ARPANET faced numerous difficulties. The number of hosts – computing machines connected to the network – had steadily increased throughout the preceding decade. The Network Information Center (NIC), whose primary duty was to assist network users with directory and general information, attempted to keep track of these machines. Part of this task involved maintaining a table that mapped numerical network addresses to names for each computer in a file called HOSTS.TXT. The NIC would update the table as new hosts came and went, and users across the network would have to download new copies frequently to maintain up-to-date information and access to other hosts. Without a correct table, hosts on the network faced the possibility of not being able to communicate with each other, so this activity was essential.¹¹

Two problems escalated around 1981 that necessitated developing a new naming system. First, the HOSTS.TXT file became too large for most contemporary hardware to consistently handle, primarily because of the increase in new hosts added to the listing. Downloading the list also became a time-consuming activity. The situation was compounded by the fact that the NIC seemed unable to update the table fast enough to keep track of new, moved, or removed hosts.¹² Though it had become unreasonable to expect the NIC to provide a perfectly accurate table, the mistakes present in some instances led to serious complaints. “In something as critically important as the Internet name registry, quality control is crucial for the continued reliable operation of the Internet,” wrote one irate user, adding “It is my belief that the NIC has failed in its function to provide trustworthy host information to Internet users.”¹³ Such difficulty clearly required a new system.

The second, and perhaps more pressing, problem involved the use of the Internet’s most popular application: email. By the early 1980s ARPANET users actively engaged in email communications with outside networks whose transport technologies were incompatible, meaning that direct connections between them were not possible. One such network was CSNET – a service funded by the National Science Foundation (NSF) for the purpose of enabling networking between university computer science departments that were not on government contracts and therefore could not directly connect to the ARPANET.¹⁴ These hosts often relied on intermittent dialup connections via telephone modems, unlike the ARPANET connections. Another of these networks was the loosely defined set of computers using the Unix-to-Unix Copy Program (UUCP). Hosts on this network also relied on dialup connections, with the added caveat that any connection had to dial (“hop” through) all of the hosts between the source and the destination.¹⁵ Both networks were able to exchange email with the ARPANET through machines called “relays” that knew how to translate between each network environment.

Complexities arose when a user had to address email to a recipient in another network. For an Arpanaut¹⁶ to send mail to someone in the UUCP world, the address might look something like ucbvax!ihnp4!harvard!bbn!craig, where each “!” – or “bang” – constituted a hop that the message had to traverse en route to its destination.¹⁷ This kind of source routing address – called a “bang-path” – presented challenges for email programs in replying, as they would have to possess some knowledge of the internal topology of UUCP. CSNET addresses faced similar problems. The state of internetwork¹⁸ emailing resulted in both an unnecessary increase in network traffic and frustration caused by returned emails that had failed to reach their intended recipients.

Designers saw the implementation of domain naming as a solution to both of these problems. In the first case, it would distribute management information so that it was decentralized, while simultaneously relieving individual hosts from having to download large tables.¹⁹ In the second case, it would provide a set of common naming practices for referring to external networks. Unity among different communications environments was one of the chief purposes for developing the system. Paul Mockapetris, the computer scientist at the University of Southern California’s Information Sciences Institute (ISI) responsible for the technical standard that became DNS, explicitly stated that “The greatest challenge and least understood problem for the domain system is sharing information between different internets.”²⁰

As networks like CSNET and UUCP increased email communications with the ARPANET, the NIC found itself asking, “Who does NIC serve?” and “Where is the boundary for the Arpanet?”²¹ Answers to both questions proved elusive as the notion emerged that outside networks needed to be “accommodated” in any internal ARPANET naming scheme.²² One put it succinctly:

As a user with an interest in more than three network communities, I am quite interested in seeing we in the Internet develop an Internet compatible naming convention for referencing other network communities. In particular I would like to see them referenced as domains. The exact level of reference (top level domain, second level domain, etc.) is less important.²³

While solving pressing technical problems, the domain system would also serve the purpose of promoting increased internetworking – a goal stated quite clearly from the earliest development discussions.²⁴ However the importance of the “level of reference” – or, more specifically, the very structure of the system’s hierarchical namespace – would become more provocative as the development pressed on.

Logics of Design

The most contentious debates that took place in the early development of the domain system surrounded the semantics of naming. More specifically, contributors to the design process argued about how to structure the hierarchical namespace, especially when it came to what would constitute the top-level. Due to the state of the networking field, the different interests of the players, and the models they brought in to make their cases, there did not exist only one logical ideal solution for the situation. Participants in these discussions argued from what can loosely be described as three logical camps: a network-based structure, an organization-based structure, and a geography-based structure.

Some of this discussion took place in meetings between concerned parties, particularly those at ISI and the NIC. However, much of the discourse occurred on a special mailing list, Namedroppers. Initially set up to address older naming issues, Namedroppers contribution expanded in 1983 to anyone who had access to email and was willing to add to the discussion, including those users on non-ARPANET networks. Jon Postel, an ISI researcher and editor of the Request for Comments (RFCs) ²⁵ who had taken a leading role in the system’s development, moderated the list.²⁶ It is also where he posted the first draft RFC concerning domains, which he co-authored. This served as a starting point for the ensuing debate.

Though lacking specific technical requirements, the draft defined domains as hierarchical administrative entities that should be created according to an administrative structure instead of one based on network topology (such as a bang-path). In the spirit of accommodating outside networks, it suggested that UUCP should be one of the initial top-level domains (TLD) under which hosts could register.²⁷ This apparent contradiction seemed to go against the very need for the system, choosing network topology for naming. It also left open the issue of what, as far as the community was concerned, constituted organizations. One suggestion was that they should be intuitive to the community, and “well-enough known that everybody of interest can find them … For our community the relevant registries would seem to be ARPA, CSNET, and UUCP.”²⁸

CSNET, UUCP, and ARPA²⁹ had been suggested quite early in the process as possible TLDs.³⁰ Because the domain system would require nameservers to properly divide the namespace, the NIC would have to use “flat” TLDs in its old HOSTS.TXT table in order to acclimate users to the new names. According to the plan, as actual nameservers came online hosts could be removed from that table. ARPA served precisely this function; its existence was temporary. CSNET and UUCP were another matter. Mark Horton, a scientist at AT&T and prolific contributor to Namedroppers, used the U.S. Postal service to illustrate the possible need for such TLDs:

The Postal Service set up their hierarchy geographically, primarily because that was a clean extensible system that fit in naturally with their delivery algorithms. In our case, I think that some degree of topological breakdown makes just as much sense³¹

Political geography was to the Postal Service what topology was to the network community. However, Horton did not accept his own proposition entirely. He felt that organizations made the best sense, and that domains should not be subdivided entirely along either geographic or topological lines. Any group of people that wished to come together could form their own organization and justify having their own TLD.³²

Not all agreed with this loose interpretation of organizations. Ed Taft, an engineer at Xerox, argued that the domain structure was “intended to reflect an existing organizational or administrative hierarchy” which consequently made network topology irrelevant.³³ Xerox hosts had long been on the ARPANET, contributing to several important networking standards. Thus it was a well-known and established organization in the community. He went on to argue in favour of making Xerox its own TLD, which would “better reflect” the structure of reality.³⁴ In this case, reality indicated that the ARPANET’s network landscape was dotted with important universities and technology companies that had long been contributors to the overall research project.

Others, however, pointed to another logical reflection of reality: geography. As Horton pointed out, the postal and telephone systems were the “best examples of huge networks that go worldwide.”³⁵ However, those with specific international ties more often made the case for geography, emphasizing that countries should be the TLDs. These voices came from two important, though interrelated, points of view.

The first was from scientists working at University College London (UCL) in the UK, where one of the first international ARPANET nodes had been established in the previous decade. UCL was an important front on many ARPANET issues that involved the international community. Steve Kille, a UCL-based Arpanaut and evangelist for international standards, argued in early 1983 that the top of the domain hierarchy should be country names.³⁶ One of his colleagues, Robert Cole, made the point that the UK networking community was already using UK at the top level, and that domain system development should consider this reality.³⁷

Cole’s message hinted at an issue that would become highly contentious throughout the decade. The UK’s Joint Academic Network (JANET) already had its own naming system up and running by 1983. Its Name Registration Scheme (NRS) used names that were very similar in appearance to proposed domain names, though with one crucial difference: they were backwards.³⁸ It made sense for the UK community to use one address in both systems, and simply transpose the order when sending email across the Atlantic.³⁹ UCL, being the gateway between ARPANET and JANET, would have to deal with this task, and so Kille, Cole, and their contemporaries had a vested interest in recommending countries at the top level.

However, this was not the sole purpose for such a recommendation. The UK networking community had also invested – as had much of Europe – in transitioning towards a set of proposed international computer networking standards under development at the time, standards which, though incomplete, had an important influence on the discourse of domain structure and semantics. Thus the second set of voices arguing for country TLDs came from those that espoused the need to develop naming with such future standards in mind.

The Coming World Standards: CCITT/ISO, IFIP, and Geography

Work on international computer networking standards had commenced in the late 1970s through two separate organizations. The Consultative Committee on International Telegraphy and Telephony (CCITT) had already created a standard for network transport, X.25. CCITT sought to create global standards for ensuring that both national and private vendors could connect using common protocols. This period also saw the beginnings of the International Organization for Standardization’s (ISO) similar efforts`. Its framework – Open Systems Interconnection (OSI) – had a seven layer model, and working groups around the world would develop standards for insertion into each layer which would eventually, as a whole, provide one common protocol set for network communications.⁴⁰

By the early 1980s, CCITT had joined ISO’s efforts, and development on individual standards accelerated with much enthusiasm throughout the decade. Many European networks already relied upon X.25 and other standards that were incompatible with the ARPANET’s TCP/IP communications protocols. This created a tension between ARPA and international standards that often appeared as an American versus European issue. Proposed international standards for electronic messaging provided a further complication. By the mid-1980s, the ARPA email standards were the most widely used, but many in the international community had committed themselves to adopting the as yet to be completed international standard for messaging which would become X.400. Many in Europe simply assumed its future implementation; the UK had firmly decided to proceed with work on this standard, and by the middle of the decade would become a world leader in its adoption.⁴¹

At the outset of the domain system’s development in 1983, the International Federation for Information Processing’s Working Group on message handling (IFIP WG 6.5) was engaged in “pre-standards” work along these lines, formulating concepts that it hoped would find their way into the ISO scheme once it was developed.⁴² Some of those working with IFIP were also Namedroppers contributors who frequently reminded the community of the differences between the domain system and IFIP work, arguing that some considerations needed to be made for future compatibility. Specifically, the IFIP system relied on a hierarchical list of “attributes” – bits of information such as last name, company, or city – that could identify the named host by narrowing down the options with each provided attribute. The most important element of this scheme, in terms of domain system development, was that countries were at the top of the hierarchy.⁴³

Elizabeth “Jake” Feinler – the head of the NIC – was certainly familiar with the concept, both IFIP and ISO-based, that countries would be the top level in a future naming system and that domains might have to be prepared to adjust accordingly. She drew a chart in 1983 that had the “world” at the top with countries below, and under “US” were the other TLDs that had already been proposed in domain discussions.⁴⁴ Governments had much interest in international standards, and as the head of an organization contracted by the government’s Defense Communications Agency (DCA), Feinler repeatedly heard that “US” would need to be at the top of the domain system in order to ensure compatibility with what seemed to be future world standards.⁴⁵ IFIP contributors also emphasized this point on Namedroppers, suggesting that perhaps each country should be given its own TLD.⁴⁶ In looking towards the future, many saw the inevitable adoption of international standards in which geography would be the top-level naming division, and the domain system – if it sought to serve an international community – would have to fall in line.

A System for Whom?

The future of networking, however, would not be determined solely by world standards. Many of the networks that would exchange email using the domain system relied on dialup connections. Since each attempt to resolve a domain name would involve polling a specific nameserver, many felt that this would require the type of expensive constant connection that seemed to be an ARPANET luxury. Christopher Kent linked this issue to another future circumstance, asking whether anyone had considered how the drop in prices of personal computers and their proliferation would affect how the domain system would be used.⁴⁷

John Gilmore, who would eventually co-found the Electronic Frontier Foundation, used the complex of increasing PC use and dialup requirements to argue in favour of topological considerations for the domain naming structure. Within several years the UUCP mail environment would be PC dominated, and many of those users would not even have a phone line dedicated exclusively to computing. They vehemently stated that the domain standards had to meet UUCP needs, or else they would go elsewhere and the ARPANET would lose compatibility with the “world network.” Gilmore therefore saw the merging of PCs with dialup connections as the future of global networking, and source-route naming, like bang-paths, provided one of the few reliable systems for such connections. He believed that development had to consider realities outside of the ARPANET’s highly connected network, writing with some contempt, “Arpanauts, please pull your heads out of your expensive sand.”⁴⁸

Also taking dialup connections into consideration, Horton wondered for whom the domain system would actually apply: “Was not the intent of the domain addressing scheme to have a framework and addressing space capable of addressing the entire world?”⁴⁹ Indeed, the ARPANET community had developed operational protocols that had become widely adopted throughout the world. Horton and others saw the domain system as one that could eventually become a similar de facto world standard for more than the ARPA community.⁵⁰ Another contributor thought that hang-ups in naming structure development came precisely from considering the system as applicable to the entire world, arguing that the current domain plan would not be the ultimate, global naming system.⁵¹ Postel saw things both ways. The lookup service being implemented with nameservers might not be useable outside of the ARPA-Internet. Yet the domain style names could be applied in many different communications environments.⁵² Thus, whether or not the actual naming service would be used by a global community proved irrelevant; the style of domain names – and thus their semantics – would most likely be important for the rest of the world no matter the technical implementation.

Synthesizing Semantics

Each of the different naming structure logics had drawbacks. Topology and network-based approaches were problematic as this type of naming had partially caused the email problems that necessitated the development of a new system in the first place. Geographic-based approaches made sense, but could not describe entities, such as multinational companies, that did not adhere to this structure. They could also lead to obvious political problems down the road. Organization-based approaches might promote a situation where every company would apply for a TLD, creating too many to keep track of and rendering the system useless.⁵³ A compromise structure that incorporated the best features of these frameworks with the widest and least controversial applicability possible was needed. The solution came in the form of generic naming.

Feinler, Horton, and others believed that no matter which TLDs were selected, there needed to be a fixed set at the top. It would avoid the problems of having too many to deal with, while structuring the system so that “any new domain that gets created in the future will reasonably fit underneath” one of the fixed domains.⁵⁴ Feinler had first suggested such a scheme in late 1982 during discussions with DCA.⁵⁵ These domains could be pre-compiled into dialup systems, removing part of the need for such hosts to query multiple nameservers regularly. Additionally, a fixed set could be decided upon that would have the virtue of neutrality, avoiding turf battles over which company or organizations should get their own spots at the top of the hierarchy.⁵⁶

In April 1984 Postel sent a draft RFC on domain requirements, co-authored with Joyce Reynolds of ISI, to Namedroppers. It used MIT, UC, and CSNET as examples of TLDs.⁵⁷ Horton responded by stressing the need for a fixed set, as the inclusion of MIT and UC seemed to indicate that every university would apply for its own TLD.⁵⁸ The following month an updated draft appeared on mailing list. It established for the first time a fixed set of TLDs, including GOV, EDU, COR, and PUB. Universities would register underneath EDU, companies under COR, and government entities under GOV. The NIC was named as the administrator of each of these generic top-level domains (gTLDs).⁵⁹ While Postel evidently had taken quite seriously the appeals for a fixed generic set, the new draft was not received without controversy.

Jeff Elman argued that the TLDs were too abstract to work properly, and that the generic set did not correspond to any entities in the real world, which could pose later difficulties for the NIC’s role as root administrator.⁶⁰ More glaringly, the draft lacked any provisions for or discussion of geography. Einar Stefferud, a key figure in IFIP work, responded to this oversight. The draft had attempted to “carve up the world and assign responsibility and authority to non-existent entities.” Certain political processes yet to be determined would decide on the domain authorities. The IFIP model recognized that “international politics must be served” by putting countries at the very top of the hierarchy.⁶¹ Implicit in this statement lay the concept that IFIP and international standards development possessed the properly neutral channels for creating a top level, along with the assumption that such standards would dictate the future of network naming for the world.

In May 1984, Postel sent a long message to Namedroppers that addressed many of the issues that had been discussed in the preceding years. In his mind, claims that the establishment of naming semantics was too political, such as Stefferud’s, failed to consider that the system needed to be put in place quickly and that there would need to be some real names to do so. Specifically calling attention to the placement of UK entities, he agreed that countries should be TLDs, but that they should not be the only TLDs, as some organizations were multinational. The gTLDs would handle these situations, and he emphasized that their importance lay in their “semantic neutrality” – the same point Feinler’s had made almost a year earlier.⁶² A meeting held at the NIC the following month determined that, through such neutrality, organizations would be able to choose the most appropriate gTLD for themselves.⁶³

After Postel’s message, the discussion on Namedroppers turned towards more technical issues. Two months later, Postel and Reynolds sent out yet another draft of the domain requirements RFC. Slight modifications were made to the generic TLDs, as COR and PUB became COM and ORG respectively. The most important addition, however, was the inclusion of countries as TLDs in addition to the generic set. Sometime between the May email and the publication of this second draft RFC, Postel and others had decided to base the two-letter country-code top-level domains (ccTLDs) on a list of abbreviations, ISO-3166, maintained by the International Organization for Standardization.⁶⁴ The compromise structure for TLDs had taken into account both organizational and geographic considerations, even using an established international standard to formulate the country names.

The inclusion of country-codes from the ISO list served another purpose as well. In 1985, Mockapetris and Postel co-authored a paper that partially ruminated on the naming system development to date. They suggested that attribute systems – such as the IFIP’s work and X.400 – could eventually be layered on top of a system like DNS.⁶⁵ In other words, the domain system could provide compatibility with the type of system being developed for international standards on a technical level. Using country-code TLDs in part reflected the will of those who argued for a semantic compatibility with these proposed standards, which would themselves use countries at the top level.

Numerous internal political influences pushed and pulled the various logics of those designing the domain system’s semantics. Topology and geography-based arguments both looked towards the future, whether in the form of expanding dialup networks or large efforts at developing international standards. Organization-based arguments attempted to quell both the chaos of unlimited TLDs and controversies that were sure to arise as people saw the hierarchy as a kind of pecking order. Instead, gTLDs provided semantic neutrality from which any organization in the world could benefit. This compromise structure, however, led to a series of unique challenges when attempting to register organizations within the system as the decade progressed.

The NIC’s Updated Role

In late 1982 government officials split the ARPANET into two parts: one was an operational military network (MILNET), the other remained the research-based experimental military network (ARPANET).⁶⁷ MILNET and ARPANET together developed into the unclassified parts of the Defense Data Network (DDN) by 1983, and the NIC, which had been providing directory assistance, host table distribution, and other important services to both communities for over a decade, became known as the DDN-NIC. The distinction was important, as the NIC would have to mediate between the needs of the operational side – ever concerned with proven, consistently operational technologies – and the ARPANET’s more experimental development of new standards and protocols.

A difference in concerns between the experimental and operational sides served as the backdrop for the NIC’s reassessment of what it was and whom it should serve. Postel contacted the head of the NIC, Jake Feinler, to inform her that he would be drafting provisional document on the new domain naming convention in the summer of 1982. The NIC, backed up with operational work, had been the organization tasked with managing the DDN namespace, and Feinler worked closely with Postel as an advisor.⁶⁸ She also saw the issue as potentially “political,” because DCA, wanting to keep the operational aspects stable, simply was not ready to jump in on domains right away. In order to build a functional system, it was important that the ARPA community not seem pitted against the operational side of things, a position that Feinler felt she could mediate because the DCA considered her their representative. Thus, she played a very active role in the planning and execution of the new system, since the NIC would have to administer the actual implementation.⁶⁹

That same day she received a draft RFC co-authored by Postel in which he provided a rough outline of the administrative structure for the system. There would be “a single contact designated the czar of domains” that would specify “the top level set of domains… and… a sub-czar for each of these domains.” Armed with a red pen, Feinler made several changes to the document replacing “czar” and “sub-czar” with “Registrar” and “administrator” respectively.⁷⁰ She crossed out Postel’s name as the “czar of top level domains” and wrote “the DOD Network Information Center” in its place.⁷¹ There could be no doubt about the role of the NIC in administering the naming system.

However, the consensus was that the NIC should only administer the Domain system for an interim period until a more qualified organization stepped forward or a new standards-based solution presented itself.⁷² As development of semantics and the naming structure of DNS proceeded throughout the early 1980s, the organization’s provisional role continually came into question. Because the Internet was expanding, some felt that the NIC had no authority to determine the criteria for TLDs.⁷³ This view, in fact, served as one of the chief arguments against a broadly-defined fixed set of top-level domains. Names such as EDU and GOV did not necessarily correspond to real-world organizations that could eventually take control of their administration. When designers first suggested COR (which eventually became COM), one Namedroppers contributor rhetorically asked “Who runs it, the US Chamber of Commerce?”⁷⁴ Again, the inclusion of country-codes in the structure created the possibility for authoritative transfer to some higher organization to be determined sometime after the forthcoming ISO standards. Until that time, Postel and the NIC would have to dole out country TLDs based on their own criteria. Similarly, the generic TLDs would not be amenable to future international standards. In terms of serving as the registrar for these domains, this left some feeling that “the NIC will be saddled with this responsibility now and forever.”⁷⁵ While waiting for some higher authority to take control, the NIC would find itself in some cases arbitrating who belonged under what top-level domain.

Developing an Application Process

In the meantime, rules had to be implemented for name registration, including the development of a standardized application. The same 1984 draft RFC that proposed country-codes at the top level included these details. Each applicant would have to provide a “responsible person” for managing domain issues, a technical contact, the name of the organization requesting the domain, and a description of at least two servers that would provide reliable name services. Postel initially defined a responsible person as someone “with authority that can give orders.” Feinler took issue with this, pointing out that anyone could give orders, and that such a definition seemed more like vague “platitudes” than an actual requirement.⁷⁶ Several months later, a more fleshed out definition appeared in the final RFC:

Responsible Person: An individual must be identified who has authority for the administration of names within the domain, and who seriously takes on the responsibility for the behaviour of hosts in the domain, plus their interaction with hosts outside the domain. This person must have some technical expertise and the authority within the domain to see that problems are fixed.⁷⁷

Such requirements were general enough to accommodate the more open scheme of the generic naming structure. A technical administrator for a university could easily fill such requirements for EDU, for example, and one could imagine similar applicability within large companies. The situation became more complex, however, in the instance of country-code domain assignment.

The first major test of country TLD registration came with the application for US. Postel attempted to register himself as the responsible person for the domain in late 1984, with ISI as his sponsoring organization.⁷⁸ His form, submitted via email, specified that he had tried his best to follow the rules even though they seemed to apply more to second-level domains than those at the top.⁷⁹ These were, of course, the very rules he had co-authored and intentionally left vague vis-à-vis country registration. The application clearly served as a test through which both the official rules and processes could be elucidated for the future. At that point the NIC had not formulated internal procedures for dealing with formal registration, and did not make a decision for several months. The following April, Postel received an official rejection. Instead of taking issue with his role as a responsible person for managing the entire country domain, or the authority of his sponsoring organization ISI, the NIC cited his failure to specify two separate nameservers – a technical requirement of domain applicants. With a few corrections, Postel became the administrator of the US TLD shortly thereafter. The test had worked, and registering a ccTLD required little in the way of official political authority on the part of the applicant, as long as the more technical specifications were met.⁸⁰

Throughout the following years, applications from other countries trickled into the NIC. Quite often they would attempt to justify their qualification for administering a given country TLD beyond what was required in the form. The application for the Netherlands (NL), for example, came via post instead of email, complete with a formal cover letter. The Center for Mathematics and Computer Science (CWI) sought to register NL on the grounds that it was an important research center with government sponsorship. Furthermore, CWI already operated an extensive IP infrastructure that served “as a major gateway for Europe to the USA, Australia, Japan and Israel.”⁸¹ Its position as an organization with technical expertise and its role as a networked campus providing international connections gave credence to its ability to properly manage the NL namespace. Such arrangements were common. National or state universities, particularly those with computer science departments involved in networking experiments, served as the sponsoring organizations for many ccTLDs.

For countries interested in either connecting to the Internet or being able to exchange email with Internet hosts, CSNET offered its services throughout the mid-1980s. In 1985 Israel requested to have CSNET host one of their nameservers. A controversy arose as the Israelis wanted the server to have only email forwarding information and not any Internet address information. In other words, all references to IL would be forwarded to a CSNET relay that would, most likely, know how to access the Israeli recipients over the phone. The effect was to make hosts within Israel essentially invisible to the Internet world.⁸² At issue was not whether a country could hide its internal structure while being, at least somewhat, present in the Internet DNS. The technical issue of forwarding all email addresses for IL – inevitably both correct and incorrect addresses – would result in a lot of unnecessary traffic as bad emails were returned to senders.⁸³ Craig Partridge eventually found that this practice had been described in earlier approved documentation,⁸⁴ and Israel joined the likes of other networks that, while not actually connected to the Internet, were able to engage in communications across boundaries.

The registration of country TLDs, then, did not come down to a single organization. Instead, a collaborative effort determined how ccTLDs would be allocated, under what technical conditions, and according to which administrative processes. Postel’s role as developer, root manager, and the initial person vetting country-code applications demonstrates this collaborative relationship, since ISI and the NIC were under separate, though related, government contracts. In 1987 Mary Stahl, Task Leader for Naming and Addressing on the NIC contract, drafted the Domain Administrators Guide which included more specific information on proper procedures. Authority for management of the root, address allocation, and other responsibilities were transferred to the NIC that same year, at which point it became the official administrator for the entire Internet.⁸⁵ Feinler kept Postel involved as a special advisor, indicating that domain administration would remain a collective concern.

Problems with Generic Naming

While delegating country TLDs provided its own set of unique requirements, no Registrar duty troubled the NIC quite as much as arbitrating whether or not organizations belonged under a given generic TLD. In particular, ORG, GOV, COM, and NET, which had been selected based on their abstract qualities, had created confusion for organizations that did not consider themselves classified under such categories. The issue became all the more complicated as the decade progressed and international users began to view the generic TLDs as if they were strictly meant for entities within the United States, even though this was not the case. Consequently the purpose of US repeatedly came into question. As the decade drew to a close, cynicism in the structure of the naming system ran high, and several NIC decisions set controversial precedents that would have important effects down the road.

One situation that both the Internet community and the NIC were unprepared to deal with was accommodating a mobile, international, packet-switched network. In late 1986, the Amateur Radio Relay League (AMPR) sought to create a ham radio-based network for running electronic bulletin board systems, AMPRNET.⁸⁶ It would entail radio operators potentially on the move, meaning that any geographic naming structure would be unhelpful. Rudy Nedved expressed his strong opinion that proposed international standards failed to take this into consideration since they relied on geographic naming structures for personal users. A truly powerful system, he argued, should not prevent him from having a “computer in my car that can receive mail while I am away”.⁸⁷

The NIC had to deal with this problem in late 1987 when, instead of applying for a domain name under one of the country or generic TLDs, members of the radio network attempted to register AMPR as its own top-level domain. Due to the “isolated yet worldwide nature of their network,” which had hosts in more than fifteen countries, they did not believe that any of the other TLDs or lower level domains applied to their situation.⁸⁸ However, DNS architects had more or less settled on the naming structure by this time, and domain applications were essentially bids for placement within that structure. Thus the NIC would have to determine where in the existing namespace AMPRNET should go. NIC employees Sue Kirkpatrick and Mary Stahl were reluctant to recommend registration under ORG, as “its definition is not so clear.”⁸⁹ Stahl herself had outlined the policy of ORG registration in her RFC in November 1987:

‘ORG’ exists as a parent to subdomains that do not clearly fall within the other top-level domains. This may include technical-support groups, professional societies, or similar organizations.⁹⁰

Because AMPRNET consisted of a small amateur group, it became unclear, even with the admittedly vague and open world of ORG, where the name belonged. After deliberating for almost six months Kirkpatrick appealed to another co-worker who eventually agreed that ORG was the best fit, adding “I still like the generalized ORG domain for things like this.”⁹¹ AMPRNET was registered as AMPR.ORG in April 1988.⁹² This was not the first time ORG found itself mired in controversy. The TLD had been, rather contentiously, suggested as a possible solution for a reflexive and important case in the Internet community: the place of the NIC itself within the naming system.

MILNET and Naming the NIC

As the adoption of DNS grew in the ARPANET and associated networks through the late 1980s, some began to question why, since it had pushed so hard for everyone else to adopt proper domain names, the NIC had not formally placed itself within the system. Throughout the decade the organization remained in the temporary ARPA domain (SRI-NIC.ARPA), leading one Namedroppers contributor to ask “Have they, like compassionate disciples of the Buddha, vowed to pass last into enlightenment? Or do they simply not know which domain they belong in?”⁹³ MILNET had intentionally delayed adopting domains until they proved ready for operational use, and since the NIC remained crucial to such operations, it too waited.

Part of the reason for splitting the ARPANET from MILNET was to ensure that the experimental pace of the former did not disturb the operational pace of the latter. When development began on domains in 1983, the MILNET opted out of immediate adoption.⁹⁴ Retaining a functioning operational status for military sites was too important for DCA to risk sudden changes. Likewise, representatives repeatedly stressed the need for systems to be compatible with future ISO standards, because the world seemed to be heading in that direction.⁹⁵ Thus, they would wait and see how development proceeded on the ARPANET side.

In order to maintain reliable communication between MILNET and ARPANET sites, however, the need for a transition plan became increasingly necessary. In 1986 Feinler described such a transition in terms of “ages,” where the “iron age” would be the complete adoption of DNS (and by implication, international standards would be modern).⁹⁶ At that time MILNET sites still relied on the pre-DNS HOSTS.TXT table, which Feinler considered the “stone age.”⁹⁷ Being stuck in such an archaic domain naming era had effects on the rest of the net by polluting email traffic with old-style names that mail programs had a difficult time parsing. The situation led Hans-Werner Braun – an NSFNET pioneer – pessimistically to declare the entire domain project a failure.⁹⁸ Horton emphasized that the DDN would need to cooperate, as most of the problems with the use of DNS were related to MILNET sites that were using the old system.⁹⁹

The beginnings of a MILNET transition came in mid-1987, just as controversy arose over the place of the NIC within the namespace. For years the Stanford Research Institute (SRI), a non-profit research institution, ran the NIC contract for DARPA and then later DCA. Some felt that it naturally belonged under ORG, while others insisted that government contractors were “large business entities which do lots of contract work for large sums of money. They belong in .COM.”¹⁰⁰ Yet the NIC provided network assistance for a variety of communities, and NET had been created for precisely those organizations that provided network services. Partridge used this fact to argue that the issue had been settled years before, though the lively debate indicated otherwise.¹⁰¹

The NIC eventually stated the reason behind its lack of proper placement in the namespace: that the name was “basically controlled by the people who pay us.”¹⁰² In other words, once plans for the DDN transition to DNS were in place, the NIC would take direction from DCA representatives. A transition plan emerged by late 1988, but progress was slow and the NIC continued to distribute the old HOSTS.TXT table to MILNET sites. The general feeling from Arpanauts was that the addiction to old ways should be cut off abruptly. Craig Partridge even suggested to one NIC employee,

Given that Christ’s crucifixion has played an important part in converting many people to Christianity, it seems to me that your crucifixion might be just the action required to complete the conversion to the domain system. When’s a good day?¹⁰³

The tongue-in-cheek comment was indicative of the tensions between the experimental and operational communities, emphasizing the importance of transition for the success of the DNS overall.

The DDN issued a bulletin in 1987 describing “Phase II” of its transition to the domain name system – the “bronze age” according to Feinler’s logic.¹⁰⁴ Over a year later, NIC hosts were placed under DDN.MIL. In August 1989 official NIC correspondence, including the management of the Namedroppers list, shifted to the new official domain name: NIC.DDN.MIL.¹⁰⁵ In attempting to place itself within the naming universe, the NIC opted for the entity that gave it official orders. This relationship would become controversial as the Internet grew.

Which Domains Are International?

As the decade drew to a close, appropriate placement of names under the generic TLDs became more difficult to determine. Countries were organizing their subdomains in ways that tempted applicants away from joining the generic TLDs. Furthermore, applicants came to view these categories as essentially American, even though they were intended to be abstract enough for international applicability. The very “semantic neutrality” that had served as the impetus behind adopting a global, generic set of TLDs came under fire. In particular, criticism and confusion surrounded the proper use of the US domain and how international organizations should register given the changing views of generic TLDs.

Though initially allocated two years prior, the US TLD had not received a single application for a subdomain as of 1987.¹⁰⁶ Blame rested with its ambiguous purpose. As the responsible person, Postel had yet to announce how it would be subdivided. He remained adamant, however, that it not be according to organization type as the generic TLDs already provided this service and were in active use. Without an alternative and in keeping with the design philosophy, this situation forced the structure based on political geography that Postel finally specified in late 1988.¹⁰⁷ Two important complications emerged from this development.

The first was that the rules for US did not follow the current practices that other countries had employed within their own TLDs. Many countries used subdomains similar to the NIC’s generic set under their own ccTLDs. For example, the UK used CO.UK and AC.UK to indicate companies and universities within its borders. The practice had benefits that overcame the ambiguities of the generic set. A Namedroppers contributor provided a salient example, rhetorically asking “would Kent.Edu be Kent State University or the University of Kent County England? British foresight has prevented this conflict.”¹⁰⁸ Such concerns were not merely hypothetical. By 1989 several Canadian universities, including Toronto and McGill, began abandoning EDU and migrating into the CA TLD. Previously, these schools had connected to the Internet through services provided by CSNET, which had also helped many universities register in EDU. Migration began when these universities acquired their own connections to the Internet.¹⁰⁹ The case was indicative of a larger trend, as the number of subdomains in EDU shrank precipitously between 1988 and 1989.¹¹⁰

The second complication involved a lack of mutual understanding about which governments should register under the GOV TLD. Official NIC policy stated, rather vaguely, that the domain acted “as a parent domain for subdomains set up by government agencies.”¹¹¹ Yet since the US domain had been structured geographically, applicants from state governments and agencies viewed it as the natural place to apply for a name. In 1989 the California Department of Water Resources attempted just that, and was rejected by Postel because he was “unwilling to register a domain as large as a state government.”¹¹² Earlier in the year the NIC set a precedent with the registration of HAWAII.GOV for the Hawaiian state government, and they continued the pattern by placing the California Department of Water Resources under CA.GOV instead.¹¹³ The following year, another California state agency attempted to register, but did not feel that it was “appropriate” to be under the agency managing the CA.GOV domain.¹¹⁴ In other words, the new applicant – whose name is not mentioned in the documentation – did not feel that its situation should be determined by the Department of Water Resources.

The University of Texas Office of Telecommunication Services faced the same dilemma when it too applied to set up a domain for state government institutions that same year. Citing the Hawaiian precedent, it proposed the straightforward TEXAS.GOV.¹¹⁵ However, a former administrator of GOV replied that the “domain is supposed to be for US government organizations (those with a “national” significance),” arguing that the Hawaii case was “probably the wrong way to go.”¹¹⁶ There seemed to be at least some agreement that GOV referred only to federal institutions.¹¹⁷

The view that GOV existed only for American entities had extended to the rest of the generic TLDs. When applying for a domain, organizations should “just pretend that the [generic] top-level domains are under .US (but in fact are not),” according to one suggestion.¹¹⁸ Crispin argued that such thinking went against the “internationalist” intentions of the generic namespace design, which had been partially ruined by the “brutal reality” of incorporating country-codes.¹¹⁹ The point was to describe what something was and not where it was. Yet most of the world seemed bent on using country-codes as the primary TLDs, a situation that left the supposedly “worldwide” generic set looking as if it only applied to the U.S.¹²⁰

No single dispute demonstrated this point more clearly than the domain application of the European Organization for Nuclear Research (CERN). As a multinational consortium with a physical location on the border of France and Switzerland, CERN applicants felt it did not belong under a specific country TLD. The EEC already considered the organization its own country to ease administrative complexities, and like any other country it should have its own domain at the very top level.¹²¹ More importantly, the generic TLDs were ruled out because they were “all managed in the USA” and were “part of American infrastructure.”¹²² The NIC offered a name under ORG, but CERN declined, taking a place under CH (Switzerland) instead– a more neutral choice, apparently, than the “semantic neutrality” provided by the generic TLDs.

As an important research institution with ties to the networking community – where Tim Berners-Lee would later develop the World Wide Web – CERN’s decision laid bare the declining notion of the generic TLDs as both neutral and international. The case was cited, along with the flight of Canadian universities, as a reason for more expanded use of the US TLD.¹²³ In preceding years others had made the suggestion that all of the generic domains be placed under it to better conform to contemporary and future international circumstances.¹²⁴ Near the end of the decade a contingent of Namedroppers contributors saw the country-codes as forward thinking, suggesting “as ISO comes along, the most significant component … will be the country code.”¹²⁵ Jake Feinler had similar feelings about US:

I believe that .US was held as a place saver so that naming used in the ARPANET/DDN environment could comply with CCITT/ISO standards. … If the ISO standards are adopted it is my understanding that US would become the topmost domain. … Since ISO requires that there be a country name I don’t see how it could be otherwise.¹²⁶

The generic TLDs, designed to be globally applicable, had in fact come to be seen as somewhat anti-internationalist in exactly the opposite manner of the intended design.

Viewing the generic TLDs as American also presented another fundamental problem. The DNS had expanded to include information about hosts not directly connected to the Internet that instead had their email pass through a relay. Indeed, this type of unity was one of the goals behind the creation of the system. The NIC had been stuck with the duties of managing generic TLDs, but still primarily served an IP-based Internet under contract from the U.S. government, which was seen as a conflict of interest. Domains had escaped into the global wild, perhaps out of the NIC’s jurisdiction. Furthermore, the internationalization of the Internet – of which the proliferation of domain registrations was merely a symptom – pushed the NIC to the limits of such jurisdiction.

Changes in the Landscape

Registration of domain names with the NIC continued steadily throughout the 1980s. In 1985, a year after the naming structure had been more or less solidified, the NIC recorded 33 domain names.¹²⁸ Merely three years later, this number reached 1,280.¹²⁹ 1988 alone saw a 67% increase in NIC registered domains, not including subdomains.¹³⁰ This rapid growth went hand in hand with an increase in the number of hosts connected to the Internet. In 1989 the Internet Engineering Task Force (IETF) found the doubling period for connected hosts to be 13 months, estimating that by the year 2000 there could be as many as 1 million.¹³¹ By the end of the decade, more of these connections were international, leading one Namedroppers contributor to describe the NIC administered gTLDs as “cultural imperialism,” while similarly pointing out that the ARPANET was no longer the “backbone” of an Internet that had grown globally.¹³²

Changes in U.S. infrastructure had partially helped create the conditions for this growth. In 1984, the National Science Foundation (NSF) began a program for the creation of a large research network that would connect supercomputing facilities across the country using ARPA developed standards and, over time, incorporating many of the ARPANET nodes.¹³³ The NSFNET, as it was called, formed a large high-speed backbone that traversed the length of the country. As more ARPA sites began to migrate to this backbone, plans were first put in place for the decommissioning of the ARPANET in June 1988.¹³⁴ Over the course of the following two years ARPANET nodes switched to the NSFNET, and the long-running research project ended in early 1990.

Several important events occurred in this period of changing network landscape. The NIC maintained its SRI contract for managing the relevant parts of the domain system throughout the transition. NSFNET’s consumption of much of the ARPANET was equally affected by its policy towards new hosts. Those that could connect directly to the network had what was called “connected status,” which required government sponsorship. The NIC, as a government service, had maintained a policy whereby the handing out of Internet identifiers required connected status. In other words, to be a full domain-using member of the Internet, hosts still required official U.S. government sponsorship. The controversial policy became more burdensome and heavily criticized as international hosts attempted to use the domain system. One instance in which the need for change in this policy became clear was with the revelation of the way that the West German TLD had been managed.

The German Question

In May 1990, an engineer at the University of Colorado attempted to access a host in what was then West Germany. He discovered two separate zones for the DE domain, which had “hidden” some hosts from the Internet community.¹³⁵ Earlier in the year CSNET had transferred authority of DE to the University of Dortmund, which served as the administrator for the domain at a time when many universities in Germany were using the domain names (and TCP/IP) internally.¹³⁶ However, many of these same institutions were not connected to the Internet due to the sheer expense of such connections or the increasingly archaic requirements for government sponsorship. As a result, administrators at Dortmund made a policy decision to implement two zones for domain naming: one that included subdomains of DE that had Internet connectivity and another that only contained information about hosts within German networks that Internet users could not directly connect to anyway.¹³⁷

German administrators were using the internal zone to ensure that email originating in Germany and addressed to another German did not pass through the U.S. while in transit.¹³⁸ Contributors to Namedroppers made the point that the policy acted as if Germany and the U.S. were the only relevant parties. Other European hosts, which made use of domains for themselves, could connect to the “hidden” German networks by other routes.¹³⁹ Thus, it still was possible for a U.S. connection to be made via one of these other European hosts.

At the heart of the matter stood the fact that hosts lacking connected status could not add their domain information into the official Internet DNS root zone for the purposes of an address-to-name (inverse) translation. This involved registration in the special IN-ADDR.ARPA domain, which, according to the old policy, required connected status due to its administrative position under the ARPA TLD. Because many German universities fell into this category, but wanted to use the protocols for naming that the Internet community had developed anyway, DE administrators continued to see a need for the split zone framework. The solution, from the German perspective, was that non-connected networks should be permitted to register in the IN-ADDR.ARPA zone.¹⁴⁰ Though divided on the immediate solution to the German question, the community generally supported a shift in policy and, in fact, the Internet Activities Board (IAB) had begun to address the issue of removing the connected status requirement earlier in the year.

The growth of the NSFNET had left the domain system in this tenuous position. As early as June 1990 it became immediately clear that connected status should not matter when determining domain registration.¹⁴¹ Vint Cerf made the switch official in August with the publication of RFC 1174. The new policy called for an end to connected status requirements for hosts that wanted to register names. More importantly, it pointed to “the rapid escalation of the number of networks in the Internet and its concurrent internationalization” as driving causes behind the shift, necessitating “further delegation of assignment and registration authority on an international basis.”¹⁴² The German issue had been merely one symptom of this internationalization. In September, the NIC received explicit instructions based on this policy shift, requiring that it “allow any registered networks to be entered into the Domain Name Server database without regard to ‘connected’ status.”¹⁴³ The policy change represented yet another distancing of the Internet from its DOD origins while expanding the ability for hosts to message reliably from around the world.

The UK and the Fall of the Iron Curtain

Germany was not the only country causing domain-induced headaches in the community. At the end of the decade, the UK’s academic network, JANET, still used a naming practice reversed from the Internet domain convention. The issue reached its zenith in the summer of 1990 when Czechoslovakia applied for its ccTLD (CS) from the NIC. Researchers in Czechoslovakia had operated a network backbone based on proprietary standards since 1984, but the Velvet Revolution and subsequent political events had sped up the desire for both more established technologies and increased international connections.¹⁴⁴ Making itself known to the globally expanding Internet seemed a good start for the Czechs, and this entailed registering with the NIC.

Word of the Czechoslovakian application sent the community into a heated discussion. UK universities had long used CS as a subdomain for computer science departments, thus leading to potentially confusing addresses like CS.UCL.AC.UK. Had the naming order been consistent, this would not have been an issue, yet because NRS to Internet translation involved reversing the names, mailers could become confused over which part of the address constituted the “real” end – CS or UK. One Dutch user summed up the potentially disastrous effects sarcastically with the hypothetical response “oh dear everythings gone horribly wrong, my mail to computing science has just headed off for Prague.”¹⁴⁵ In reality of these kinds of errors occurring probably was marginal. Even before Czechoslovakia finally registered with the NIC in December 1990, it possessed merely ten UUCP sites.¹⁴⁶ Still, the very threat of such an incident brought to light issues of where the UK fit in the Internet’s view of the networking world and intimations of quite negative attitudes towards ISO standards, X.400 in particular.

Many Internet users suggested that those in charge of JANET should simply reverse all of their names, bringing them in compliance with Internet practice. NRS defenders rebutted by arguing that JANET was not on the Internet, and that its convention operated correctly according to its own protocols and administration. How JANET’s parent organization – the Joint Network Team (JNT) – ran the network was a matter of internal policy.¹⁴⁷ Erik Naggum, a notoriously vocal programmer, responded to these assertions with an Internet-centric ultimatum: “If you want to talk to or with the Internet, follow Internet rules.” ¹⁴⁸ Registration with DNS had become the primary method of making external networks known to those on the Internet. Thus a larger issue than the order of names implicitly came into play, specifically, whether or not external networks lacking direct Internet connections should have to accommodate Internet-developed standards for the sake of maintaining workable email. After all, Internet protocols were not “official” standards from the British perspective, as ISO was still working on its own international standards.

However, by the summer of 1990 the Internet’s TCP/IP technology had been adopted by numerous private networks within Europe, many with direct Internet connections, to such an extent that some considered it the de facto dominant network on the continent.¹⁴⁹ Likewise, this same contingent came to see the domain system as the de facto naming standard, going as far as specifically calling it the “international standard” against which the UK had become the odd man out.¹⁵⁰ The predictions of those like Horton, who during the namespace design phase had suggested that domains could become a world standard, had apparently come to pass.

Of course, many in the UK community did not share this view of domains. They had understood the inverted name problem for years, but insisted that NRS served as a mere stepping stone to the ISO standard for electronic messaging, X.400. The overall OSI networking standards package development had progressed slowly throughout the decade. The JNT had, however, made firm commitments to transition their network to OSI as early as 1984.¹⁵¹ Since X.400 was completely different from both domains and the NRS there was no need to resolve the inverted name issue. Though globally workable implementations of X.400 had failed to emerge by 1990, those defending the UK naming practice continued to fall back on the argument that OSI would solve the problem eventually by simply replacing everything else.¹⁵²

UK complacency, many believed, had led to the problem faced with Czechoslovakia’s TLD registration. As one user wrote, “…the US creates working code that they distribute free … We in Europe [are] experts in large never ending investigations. If we don’t have a valid ISO standard, [we] sit on our ass and wait for it.”¹⁵³ The view was not entirely fair. The JNT had repeatedly faced financial problems throughout the 1980s, in one case even threatening to sue the former administrators of the NRS at the Salford Computing Centre for suddenly withdrawing from the scheme’s development. In the face of these troubles, they managed to earmark £54 thousand for a new high-speed link between JANET and the Internet in 1987.¹⁵⁴ It appears that they were, much like the ARPANET community, seeking to keep their network operational while increasing connections to the outside world. Intentional idleness played little role in these decisions; future world standards would reduce costs and solve problems.

Still, the perception of idleness naturally led to scorn for the very standards that the UK had been waiting for. Horton had long ago described X.400 as an “abortion.”¹⁵⁵ Indeed, the Internet community generally viewed OSI work with some reservation, as no complete implementation had demonstrated its viability in the way that Internet protocols had. Holding out for them was “absolutely crazy” since a final product was still “a long way off.”¹⁵⁶ The JNT and the UK became punching bags for those that wanted to swing at OSI or were frustrated by a major country impeding communications due to its internal policies. Naggum vented his frustrations by writing, “I have a map of Europe on my wall that has a nice blue color off the northwest coast of France. Beautiful.”¹⁵⁷ The sentiment came through clearly: the UK might not be on the “map” of the future world internetwork if it did not make efforts towards a solution. Proper use of domains constituted a way of remaining on this map, one increasingly drawn with an Internet view of the entire networking world.

The NIC and the Gulf War

While the world’s conceptual map of networks changed considerably throughout 1990, so too had the its geopolitical map. After the Iraqi invasion and attempt at annexing Kuwait in the summer of 1990, a USENET post listed the ISO-3166 entries for both countries (IQ and KW) facetiously asking “What will be the new codes?”¹⁵⁸ Jokes aside, that November several users noticed that KW had suddenly been removed from the root of the DNS. “It’s one thing seeing all this hype (over & over) in the news,” wrote one Namedroppers contributor concerned with the removal. “This kinda makes it a little closer to home (in a strange way).”¹⁵⁹ Some even wondered whether removal had been requested voluntarily or by force.¹⁶⁰ The action had not escaped the attention of the IAB, which asked the NIC whether or not the removal “was a reaction to the current political situation in the Middle East.”¹⁶¹ As a contracted organization serving the U.S. military, the NIC’s role in the removal was a serious matter.

NIC employees reported that they had allocated KW to the University of Kuwait in November 1989 with the help of CSNET, who served as the technical and administrative contact.¹⁶² This arrangement was common practice at the time as demonstrated by its similar registration of Israel five years earlier. Meanwhile, CSNET personnel had noticed that, not surprisingly, no traffic had come from the KW domain since the invasion of Kuwait several months prior. They used this fact as technical justification for requesting the removal of the domain in late October. Because CSNET was the technical contact for the domain, the NIC had followed “standard policy for the removal of domains in this situation.”¹⁶³ Yet it remained unclear whether the University of Kuwait had made a request to their technical contact. Instead, a lack of network traffic was taken as a sign that hosts no longer operated in that domain.

Charles Hedrick, one of the early contributors to Namedroppers, had warned the community of almost exactly this situation in the earliest months of domain system development. Responding back in 1983 to a draft RFC, he characterized the policy of the NIC administering large portions of the system as “unsettling” due to its government ties. More presciently, he concluded that “there will always be some excellent policy reason why it can’t include all of the domains that should be included.”¹⁶⁴ Though the NIC had followed accepted policy for removing the domain, the fact that the IAB felt the need to check for political motivations indicated that the organization’s standing as a U.S. government service had grown more unsuitable for a rapidly globalizing Internet.

Internally, the NIC also found it more difficult to mediate between this globalizing Internet and the demands of their contracting agency. After RFC 1174 had officially removed the requirement for connected status in September 1990, the NIC updated software and modified its databases in adjustment. In December, DCA sent a letter saying that the NIC would have to “roll back” these changes, as they had neither been paid for nor authorized through official government channels.¹⁶⁵ The agency, it seems, was either unaware or had not recognized that the changes required by RFC 1174 had come at the behest of the Federal Networking Council (FNC).¹⁶⁶ The letter clearly showed that the DCA had little understanding of the changes themselves and how the DDN still maintained important policy ties with the greater Internet.

Jose Garcia-Luna, the new head of the NIC, drafted a strongly worded response several days later. He accepted DCA’s decision not to pay for the changes, but expressed serious concerns with the agency’s failure to understand the “explosive” growth of the Internet and the role of the domain name system worldwide.¹⁶⁷ Concerning the request to revert the database and programming changes, he warned that

one of the setbacks that would occur if the NIC were to roll back its database to a pre-RFC 1174 state is that several hosts involved in the Operation Desert Shield (ODS) initiative would cease to exist from the standpoint of the host table or the domain name system, i.e., they would be unreachable…¹⁶⁸

Garcia-Luna had not merely conjured up a hypothetical threat. Beginning in September, the NIC had allocated a block of addresses and domains specifically in support of Desert Shield by request of the military.¹⁶⁹ Putting the obviously disastrous DCA demand in the context of contemporary military operations was a clever tactic evident of the NIC’s mediating position.

Such position did not come without frustration. The response, intended for editing by a co-worker, was peppered with Garcia-Luna’s vitriolic commentary, at one point referring to DCA as “STUPID AND IGNORANT” while instructing them to “GO PLAY TOUGH MANAGEMENT AT THE ZOO!”¹⁷⁰ He obviously felt that government overseers should allow the NIC to operate with more autonomy, as their existence relied upon paying close attention to changes in the networking world to which DCA was oblivious. The “tough management” – or red tape – had led to the potentially dangerous scenario of government accidentally taking itself offline due to internal disputes. Thus, despite its position as mediator, the exchange demonstrated the unsuitability of the DDN-NIC as the central registrar of the root.

After a competitive-bidding process, SRI lost the NIC contract to Government Systems Inc. (GSI) in 1991.¹⁷¹ At that point, registrar duties for some of the generic top-level domains transferred to GSI’s subsidiary Network Solutions, while responsibility for the rest was split between two other contracts.¹⁷² As the 1990s progressed and the Internet commercialized, the U.S. government decided it could no longer fund the registration of domains free of charge. Domain names, then, became a financial concern, and this period saw much controversy over what organization controlled the root. RFC 1174 had paved the way for both the coming commercialization and the changes in the NIC contract, thus marking and end to the period of early Internet expansion and domain implementation.

Archival Sources

The NIC Collection, Computer History Museum, Mountain View, California

- NIC Naming and Addressing Documents 1972-1999, Boxes #1 and 2

- NIC Contract Materials: Monthly Status Reports Box #4

Namedroppers email list, 1983-1990

- Available on CD-ROM by request from the Computer History Museum

TCP-IP email list

- Available on CD-ROM by request from the Computer History Museum

USENET eunet.misc messages

- Archived and searchable from 1982 onward at Google Groups (http://groups.google.com)

British National Archives, Kew, United Kingdom

- Department of Education and Science: Computer Board for Universities and Research Councils, 1979-1987. ED 238/45

- Papers of the Network Advisory Committee, 1983-1986. ED 238/54

Proceedings of the Internet Engineering Task Force, 1985-1990

- Archived online at the IETF’s website (http://www.ietf.org)

Other Primary Sources

Cole, Robert. “Technical Report 106: Naming, Addressing and Directories in Open Systems.” Department of Computer Science, University College London, 1985.

Kirstein, Peter. “Technical Report 111: UK-US Collaborative Computing Progress Report October 1984-October 1985.” Department of Computer Science, University College London, 1985.

———. “Technical Report 116: Final Report on the Project Message Services and Directory Development.” Department of Computer Science, University College London, 1986.

Stefferud, Einar, and Ole Jacobsen. “Proceedings of the IFIP TC 6/WG 6.5 Working Conference on Message Handling Systems and Distributed Applications.” Costa Mesa, California, USA, 1988.

Secondary Sources

Abbate, Janet. Inventing the Internet. Cambridge: MIT Press, 1999.

Benkler, Yochai. Wealth of Networks. New Haven: Yale University Press, 2006.

Castells, Manuel. The Network Society: A Cross-Cultural Perspective. Northampton, MA: Edward Elgar Pub., 2004.

———. The Rise of Network Society. Oxford: Blackwell Publishers, 1996.

Ceruzzi, Paul E. Internet Alley: High Technology in Tysons Corner, 1945-2005. Cambridge: MIT Press, 2008.

Clark, Charles S. “Regulating the Internet.” CQ Researcher 5, no. 24 (1995): 561-84.

DeNardis, Laura. Protocol Politics: The Globalization of Internet Governance. Cambridge, MA: MIT Press, 2009.

Froomkin, A. Michael. “Of Governments and Governance.” Berkeley Technology Law Journal 14 (1999): 617-34.

Grewal, David Singh. Network Power: The Social Dynamics of Globalization. New Haven: Yale University Press, 2008.

Hafner, Katie, and Matthew Lyon. Where Wizards Stay up Late: The Origins of the Internet. New York: Simon & Schuster, 1996.

Hauben, Michael. Netizens: On the History and Impact of Usenet and the Internet. Los Alamitos, CA: IEEE Computer Society Press, 1997.

Kesan, Jay P, and Rajiv C Shah. “Fool Us Once Shame on You - Fool Us Twice Shame on Us: What We Can Learn from the Privatizations of the Internet Backbone Network and the Domain Name System.” Washington University Law Quarterly 79 (2001).

Kim, Byung-Keum. Internationalizing the Internet: The Co-Evolution of Influence and Technology. Cheltenham, UK: Edward Elgar, 2005.

Leaffer, Marshall. “Domain Names, Globalization, and Internet Governance.” Indiana Journal of Global Legal Studies 6, no. 1 (1999): 139-65.

Licklider, J.C.R. “Man-Computer Symbiosis.” IRE Transactions on Human Factors in Electronics 1, no. 1 (1960): 4-11.

Liu, Joseph P. “Legitimacy and Authority in Internet Coordination: A Domain Name Case Study.” Indiana Law Journal 74 (1999).

Mueller, Milton. Ruling the Root: Internet Governance and the Taming of Cyberspace. Cambridge, Mass: MIT Press, 2002.

Partidge, Craig. “The Technical Development of Internet Email.” IEEE Annals of the History of Computing 30, no. 2 (2008): 3-29.

Quarterman, John S. The Matrix: Computer Networks and Conferencing Systems Worldwide. Bedford, Mass: Digital Press, 1990.

Rony, Ellen, and Peter Rony. The Domain Name Handbook. Berkeley: Publishers Group West, 1998.

Salus, Peter H. Casting the Net: From Arpanet to Internet and Beyond. Reading, Mass: Addison-Wesley Publishing Co., 1995.

Schill, Stefan. “Networking in Czechoslovakia: Efforts and Results.” Computer Networks and ISDN Systems 19, no. 5 (November 1990): 186-88.

Segaller, Stephen. Nerds 2.0.1: A Brief History of the Internet. New York: TV Books, 1998.

Shirky, Clay. Here Comes Everybody: The Power of Organizing without Organizations. New York: Penguin Books, 2008.

Simon, Craig Lyle. “Launching the Dns War: Dot-Com Privatization and the Rise of Global Internet Governance.” Dissertation, University of Miami, 2006.

System, Committee on Internet Navigation and the Domain Name. “Signposts in Cyberspace : The Domain Name System and Internet Navigation.” edited by National Research Council. Washington, DC: National Academies Press 2005.

Winner, Langdon. The Whale and the Reactor: A Search for Limits in an Age of High Technology. Chicago: University of Chicago Press, 1986.

Zittrain, Jonathan. “ICANN: Between the Public and the Private - Comments before Congress.” Berkeley Technology Law Journal 14, no. 3 (1999): 1071-93.