Preface to the Online Version
A professor of mine once opened a book with: “Writing is hard.” Too true. But having written? Now there’s a sweetness rarely matched elsewhere in life.
I researched the following work in a mad-dash year and a half, as part of the CU/LSE dual degree in International and World History, the bulk of the writing occurring during a four week period in Spring 2011. Back then, I couldn’t find many others working on esoteric topics in the history of the Internet, let alone the DNS. But a lot can happen in a decade, and today the history of the Internet – and computing history generally – are burgeoning fields.
Aside from (miraculously) allowing me to pass my program, I believe this paper can serve some useful purpose by being published openly. For those curious about the history of the Domain Name System, I hope it can provide scholars with some guide to potential sources, an idea of the early timeline, information about relevant organizations, and some interesting tidbits along the way. Others will find it, I believe, to be a potent cure for insomnia.
Due to LSE’s strict submission requirements, I did not have space for acknowledgements when I first submitted this a decade ago. I’m taking this opportunity to rectify the omission. First, I’d like to thank Lincoln’s Inn Fields for existing, and Don Quixote Cafe on Kingsway for making affordable paninis that fuelled the creation of the present work. I would also like to thank the Computer History Museum in Mountain View, CA for providing generous access to its collections, and to Jake Feinler in particular for both creating her archive and patiently sitting with me as I pored over her material. Sincere thanks also goes out to Line Lillevik, for always doing the impossible; the late Adam McKeown, for encouraging us to think big; Matt Connelly, a living reminder that history is important, relevant, and fun; my advisor Paul Keenan for his advice and for taking a chance on me; and to my parents, who dutifully slogged their way through pages and pages of acronyms. Finally, I’d like to thank my CU/LSE classmates, without whom I may never have completed this.
Today’s Internet is a remarkable technical accomplishment, a series of globally interconnected computer networks that facilitates the exchange of information in the blink of an eye. As it has become an integral part of the world economy, its web and email addressing have become almost universally recognized. In the not-too-distant past, however, the Internet was not globally connected; its standards and protocols a matter of contention, its email difficult to deliver and lacking a common format. From this seemingly chaotic period emerged a set of solutions that would have a profound impact on the evolution and success of the Internet as a whole.
One of these solutions is the Domain Name System1 (DNS), which maps the numerical information necessary for one computer to connect to another to human-readable names such as email and web addresses. Its development and implementation in the 1980s occurred during a significant period in the history of computer networking. The U.S. Department of Defense Advanced Research Projects Administration’s (ARPA) experimental computer network – by many accounts the progenitor of the modern Internet, the ARPANET – had entered its final decade.2 Simultaneously, demands for the standards and technologies it had developed amplified across the globe, as did the desire for increased email communication and connectivity. All of this came before the Internet was commercial, when the network was not yet public, and when personal computers had just hit the market. The intimate relationship between DNS and these developments beckons historical examination.
However, few academic Internet histories exist. Those that do concentrate on the creation of the ARPANET in the 1960s and its transformation into today’s Internet. Janet Abbate’s seminal work, Inventing the Internet, extensively chronicles the origins of various communications protocols and their relationship to the ARPANET. However, it dedicates only a few pages to DNS development,3 while other histories of the Internet barely make mention of it at all.4 The most complete account of DNS, Milton Mueller’s Ruling the Root, devotes a chapter to the system’s development, but focuses on the origins of domain names as property – a situation that emerged much later in the mid-1990s.5 Thus the initial development and early use of the system is underrepresented in the already scant historiography.
Previous texts have not addressed how the compromise DNS naming structure of generic and country-code top-level domains (gTLDs and ccTLDs6) was decided, how names were initially registered, and how both of these issues contributed to and were affected by the growth of the Internet internationally throughout the 1980s. The answers to these questions lie in an account of the internal social and political landscape of computer networking during the period, wherein the structure and applicability of the domain namespace was one of the more provocative issues within the Internet community. Such communities are defined within the field of Science and Technology Studies as “epistemic communities” that maintain “internal coherence even though [their] members may have different political and economic interests.”7 What constitute important political issues to this community internally may not necessarily relate to the politics of the outside world, though the two certainly interact.
Because these communities rely upon a delicate balance between internal and external politics, the technologies they develop are also imbued with such politics. Langdon Winner describes this as a dual relationship, in which the development community deals with its politics while creating a technology, but the resulting “technological artifact” also has its own politics, affecting the community and wider world after it has been implemented. The relationship “suggests that we pay attention to the characteristics of technical objects and the meaning of those characteristics.”8 Thus, an examination of the development and initial use of the DNS namespace allows for a more nuanced and detailed account of the networking community in the period. The initial compromise structure for the namespace reflected the outlook of the community in the early 1980s, one that became obsolete as the decade drew to a close. The inherent politics of the naming structure and its administration consequently influenced changes within the community as a whole, in particular the expansion of potential Internet connectivity.
Sources include meeting notes, reports, conference proceedings and other contemporary administrative documents. Technical standards and guides are also fundamental; they are still hosted online as the community continues to develop new protocols to this day. The most important sources, however, are emails – both in hard copy from the NIC Collection at the Computer History Museum and from saved electronic copies of mailing lists from the era, particularly those directly concerning DNS issues.9 These are important not just as valuable correspondence, but equally because email difficulties necessitated the development of domains in the first place. Together these sources provide unique insight into the internal social and political circumstances of the community during the 1980s.
In the 1980s naming issues brought forth competing teleologies of world networking, which profoundly influenced the semantic structure of DNS. Once established, that structure gleaned new political implications as networking expanded internationally. These implications then changed the way the community saw itself within the world, and affected the methods by which it would come to include those outside of its boundaries. Attempting to describe the networking world through domain naming both resulted from and contributed to the expansion of the Internet.
This work begins with the internal debates leading to the development of the DNS namespace in the early 1980s, including the role of proposed international standards. It then moves on to the development of the Network Information Center’s (NIC) early administration, problems experienced in categorizing entities within the namespace as the system came into use, and the change in the perception that the system possessed “semantic neutrality,” an issue embedded in a period of important worldwide expansion. The final section will address the importance of DNS in expanding the ability of external networks to connect to the Internet, along with controversies that mired the NIC late in the decade, demonstrating the controversial position that the NIC held between networking politics and international politics.
Developing the Namespace
There is a theory which states that if ever anyone discovers exactly what domains are for, and why they are here, they will instantly disappear and be replaced by something more bizarre and inexplicable. There is another which states that this has already happened.10
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.11
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.12 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.”13 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.14 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.15 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 Arpanaut16 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.17 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 internetwork18 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.19 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.”20
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?”21 Answers to both questions proved elusive as the notion emerged that outside networks needed to be “accommodated” in any internal ARPANET naming scheme.22 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.23
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.24 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) 25 who had taken a leading role in the system’s development, moderated the list.26 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.27 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.”28
CSNET, UUCP, and ARPA29 had been suggested quite early in the process as possible TLDs.30 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 sense31
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.32
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.33 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.34 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.”35 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.36 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.37
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.38 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.39 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.40
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.41
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.42 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.43
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.44 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.45 IFIP contributors also emphasized this point on Namedroppers, suggesting that perhaps each country should be given its own TLD.46 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.47
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.”48
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?”49 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.50 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.51 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.52 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.
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.53 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.54 Feinler had first suggested such a scheme in late 1982 during discussions with DCA.55 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.56
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.57 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.58 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).59 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.60 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.61 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.62 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.63
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.64 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.65 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 System in Practice: The NIC, Registration, and Semantic Neutrality
The second node, the NIC, was soon installed.
The Network Info Center, it was called.
Hosts and users, services were touted:
To the NIC was network knowledge routed. 66
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).67 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.68 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.69
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.70 She crossed out Postel’s name as the “czar of top level domains” and wrote “the DOD Network Information Center” in its place.71 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.72 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.73 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?”74 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.”75 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.76 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.77
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.78 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.79 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.80
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.”81 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.82 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.83 Craig Partridge eventually found that this practice had been described in earlier approved documentation,84 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.85 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.86 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”.87
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.88 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.”89 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.90
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.”91 AMPRNET was registered as AMPR.ORG in April 1988.92 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?”93 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.94 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.95 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).96 At that time MILNET sites still relied on the pre-DNS HOSTS.TXT table, which Feinler considered the “stone age.”97 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.98 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.99
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.”100 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.101
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.”102 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?103
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.104 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.105 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.106 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.107 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.”108 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.109 The case was indicative of a larger trend, as the number of subdomains in EDU shrank precipitously between 1988 and 1989.110
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.”111 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.”112 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.113 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.114 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.115 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.”116 There seemed to be at least some agreement that GOV referred only to federal institutions.117
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.118 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.119 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.120
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.121 More importantly, the generic TLDs were ruled out because they were “all managed in the USA” and were “part of American infrastructure.”122 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.123 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.124 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.”125 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.126
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.
The International System: The Net Grows Up, the Net Grows Out
Domain names; they’re not just for IP anymore…127
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.128 Merely three years later, this number reached 1,280.129 1988 alone saw a 67% increase in NIC registered domains, not including subdomains.130 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.131 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.132
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.133 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.134 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.135 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.136 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.137
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.138 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.139 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.140 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.141 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.”142 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.”143 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.144 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.”145 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.146 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.147 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.” 148 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.149 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.150 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.151 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.152
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.”153 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.154 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.”155 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.”156 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.”157 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?”158 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).”159 Some even wondered whether removal had been requested voluntarily or by force.160 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.”161 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.162 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.”163 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.”164 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.165 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).166 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.167 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…168
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.169 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!”170 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.171 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.172 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.
Naming is a uniquely political act. For the Internet community, it involved an entire complex of issues including how the network world was structured and how it would be structured in the future. While necessary for solving important technical problems, Postel and Mockapetris had recognized domain naming as a “substantial human problem,” emphasizing how “from a political sense these names are all-important.”173 The human problem, evidently, could not be entirely separated from the technical. Competing logics for the design of the namespace attest to this fact. Designers of the system, including Namedroppers contributors, had to synthesize technical realities – such as the ability to name external networks and the important organizations in the ARPA-Internet – with broader structures existing outside of the network. In some cases, this involved consideration for forthcoming global standards (ISO), in others the rapidly changing nature of computers and network use (such as dialup connections) demanded attention. The community of users from diverse worldviews vetted the options, and their work resulted in the compromise namespace reflecting the unique social conditions of its creation.
More importantly, the semantic structure of the system was designed with different futures in mind. The seemingly inevitable coming of global networking standards from ISO undoubtedly influenced the inclusion of the country-code TLDs, designed specifically to take over for each country at the top of a future ISO-determined hierarchy. In this version of the future, the domain naming convention would not be a world standard, and was merely an interim solution until the world networking community had adopted more appropriate alternatives. The other future provided a neutral framework that sought relevance on a global scale. Generic TLDs would best describe the contemporary ARPA-Internet while leaving room for others throughout the world to join the relevant categories. Through such global openness the domain convention could become a world standard.
That domain applicants came to view the generic TLDs as American represents an important shift in the system’s history. Organizations began to abandon the gTLDs for their respective ccTLDs, and not simply because they wanted to be prepared for a future under ISO standards. The thin veneer of “semantic neutrality” failed to hold up against the association of NIC-administered TLDs with the U.S. government, an association that rendered irrelevant the social conditions that had led to the creation of gTLDs in the first place. To a future Internet that would involve these generic names, and in theory a global standard of domain naming, this stigma was counterproductive. Still, domain applicants had interpreted a political connotation from the namespace very different from the intent of the original compromise design.
It was through this compromise structure and its administration in the late 1980s that geopolitics exposed conflicts and inconsistencies within the community. Czechoslovakia’s post-Communist networking aspirations and subsequent attempt to register its ccTLD forced the community to address the long-standing issue of UK naming backwardness. It likewise created a space for criticism of those who were waiting for ISO standards instead of adopting the functional Internet-created protocols. This led many to push compliance with Internet customs on those not connected to the Internet at all. At stake was a growing ability for the world to communicate electronically. If a network wanted to email reliably with the largest number of other hosts, it would have to adopt the Internet’s view of the world – a view circumscribed by domain naming.
The NIC itself had to face quite pressing geopolitical realities as it dealt with these issues, which complicated its role as mediator between the military and the wider Internet during a period of proliferating international connections. The Gulf War incident – a direct consequence of the internationalizing effort of RFC 1174 – exposed this difficulty, demonstrating that the close ties between the NIC and the military probably did not represent the best interests of the Internet community by the end of the decade. Likewise, RFC 1174 resulted in part from the escalating demands for full inclusion in the NIC’s database. By attempting to describe their view of the entire networking world via domains, the Internet community had given external entities the motivation to actually connect. The networks of the world had acquired an appetite for reliable global messaging, and would take what they could of ARPA-created standards. Domains were no exception.
The importance of this period in Internet history does not simply lie with the fact that the structure of the DNS was a consequence of the unique outlook and predictions of the Internet community in the early 1980s, true as that may be. It also illuminates the unique internal nature of that community in the first place. Likewise, once the structure had been established, its semantic and administrative features took on political implications of their own that had the effect of increasing demand for the inclusion of those with non-connected status.
Histories that fail to address these concerns give the impression that the system was quickly developed according to the most logical structures with minimal controversy. A consequence of such accounts is the imprecise dating of some events relative to others. For example, the research presented here has dated the adoption of the ISO-3166 country-code list to a two-month period in the summer of 1984, not 1990 as one source claims.174 While this distinction may seem overly precise, the difference places the adoption before rather than after the elimination of the connected status requirement – an event in part caused by the varying political interpretations of the compromise domain structure in the first place. Without appropriately analyzing this early period, later histories of DNS will lack the context necessary for not only understanding the origins of the system, but the ways that various internal and external social and political circumstances can change the interpretations of its structure.
A clear relationship existed between the development of the semantics and administration of the DNS and the internationalization of the Internet throughout the 1980s. The semantic structure of the system is a technological artifact that illuminates part of this process. Just as names humanized IP addresses, the DNS made the expansion of communications a practical, rather than technical, issue for the Internet community. Its administration was always a matter of a certain amount of controversy, whether in the nature of its centralization in a government-contracted organization, or through the way it categorized those it attempted to describe. While today’s Internet may be globally connected and seemingly less chaotic, these issues have not disappeared. Only through an examination of the 1980s can domain issues be understood with sufficient depth.
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.
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.
Appendix A: How DNS Works
All communications on today’s Internet use the Internet Protocol (IP). For two computers to talk to each other, they need to know where to send information. An “IP Address” provides this. It’s easiest to think of IP addresses as the “language” that computers must use in order to speak to each other. IP Addresses most commonly appear as four numbers separated by dots (192.168.0.1). These addresses are not very intuitive, so a system that links an IP address to a specific name was created (the Domain Name System).
Domain names are most clearly found in email addresses, and constitute everything after the “@” sign, for example, lse.ac.uk is a domain name. Each part of the name (uk and lse and ac) is considered a separate “domain.” Because they are hierarchical from right to left, ac is considered a “subdomain” of uk. This also means that lse.ac.uk is linked to a specific IP address. It requires that some database on some server somewhere in the world have a table that links lse.ac.uk to 192.168.0.1 (or whatever the IP address is).
Having one table on one system for every name in the world would, however, cause serious congestion problems, so the system is divided (“distributed”) along hierarchical lines. The diagram below shows how this works:
To resolve address for lse.ac.uk, the computer asks the “root” server whether it knows the IP number. It doesn’t, but it does know the IP address of a different server somewhere that has information for uk, and so it provides that. The uk server also doesn’t know the IP address, but it does have the address of a different server somewhere that knows about ac, and so on until lse.ac.uk is reached and the desired IP address returns to the original computer. After that, communications across the Internet can commence. All of this happens in a fraction of a second.
The system is hierarchical in one other way: each domain constitutes a level of “authority,” meaning that it has responsibility for knowing all of its subdomains and keeping quality information about them. This distributes the entire set of names in the world so that one central authority or nameserver does not possess too much information. Thus domains are both technical and administrative entities.
Appendix B: Glossary
|ARPANET||The U.S. government-funded experimental packet switching network first put into service in the 1960s. The network in which the Internet Protocol was developed and used, and which many consider the progenitor to today’s Internet.|
|CSNET||A dialup network that connected computer science departments without government contracts to ARPANET sites in the 1980s.|
|Feinler, Elizabeth||The head of the NIC (who went by the name “Jake”) until she left SRI in 1989. Feinler’s role in DNS development has been underplayed, as her concepts eventually made their way into the semantic structure.|
|Horton, Mark||A USENET pioneer and advocate for UUCP. He worked at Bell Labs during much of the 1980s.|
|Host||A term synonymous with “computer” as we would use it today. In the early days of the ARPANET, hosts were large computers connected to multiple “terminals” sharing computing power and time. This is why there can be multiple users at a single host.|
|IFIP (International Federation for Information Processing)||An international non-profit organization working towards networking and technical standards. The Working Group on Message Handling Systems, WG 6.5, developed “pre-standards” for ISO, some of whose concepts made it into X.400 and other standards later on.|
|Mockapetris, Paul||The ISI scientist who drafted the technical specification for DNS and its implementation, initially in RFCs 882 and 883.|
|Namedroppers||A mailing list, open to all who wished to contribute, that dealt with DNS development and technical issues. Also the name of the official Working Group on DNS development|
|Nameserver||A physical computer that processes domain name information, and has the IP address of a desired host or the address of another nameserver that might have that information.|
|Namespace||A context in which names are identified or associated with both entities that they point to or try to describe.|
|NIC (Network Information Center)||The central entity that provided directory assistance and other organizational support for the ARPANET, MILNET, and, to some extent, other networks. Administered the root of the DNS and most gTLDs throughout the 1980s.|
|NSFNET||A high-speed networking project of the National Science Foundation that ran from 1985-1995. It eventually incorporated many ARPANET sites and became the backbone for the Internet in the 1990s.|
|Postel, Jon||RFC editor and scientist at USC’s Information Sciences Institute until his untimely death in 1998. He was a contributor to many Internet standards and fundamental to the development of DNS. He also served as the administrator of the US TLD until 1997 and moderator of the Namedroppers mailing list.|
|RFC (Request for Comments)||A document that is put out to the Internet community in the hopes that it will become a standard for that community. Jon Postel was the RFC editor throughout the 1980s.|
|Root||The topmost level of the domain hierarchy. Contains all of the TLDs. Root nameservers likewise hold information about the TLDs.|
|TCP/IP||The “Internet Protocol Suite.” A series of technologies, called transport, that allow communication between networked computers. Today’s Internet can be defined as all connected machines using this transport technology. It is fundamentally incompatible with other transport technologies, such as X.25.|
|X.25||The transport technology initially developed for CCITT that was widely used in Europe and elsewhere in the 1980s. It eventually became the transport layer standard for OSI’s seven-layer standardization model.|
|X.400||An international standard for computer-based messaging developed in cooperation with ISO for Open Systems Interconnection|
Appendix C: List of Acronyms
|AMPR||Amateur Radio Relay League|
|ARPA||Advanced Research Projects Administration|
|CCITT||Consultative Committee on International Telegraphy and Telephony|
|ccTLD||Country-Code Top-Level Domain|
|CERN||European Organization for Nuclear Research|
|DCA||Defense Communications Agency|
|DDN||Defense Data Network|
|DNS||Domain Name System|
|FNC||Federal Networking Council|
|gTLD||Generic Top-Level Domain|
|IAB||Internet Activities Board|
|IETF||Internet Engineering Task Force|
|IFIP||International Federation for Information Processing|
|ISI||The Information Sciences Institute at the University of Southern California|
|ISO||International Standardization Organization|
|JANET||Joint Academic Network|
|JNT||Joint Network Team|
|NIC||Network Information Center|
|NRS||Name Registration Scheme|
|NSF||National Science Foundation|
|OSI||Open Systems Interconnection|
|RFC||Request for Comments|
|SRI||Stanford Research Institute|
|TCP/IP||Transmission Control Protocol/Internet Protocol|
|UCL||University College London|
|UUCP||Unix-to-Unix Copy Program|
For a detailed explanation of how DNS works, see Appendix A.↩
In modern use, the term “Internet” refers to all connected systems using the Internet Protocol suite (TCP/IP). In the 1980s, however, “Internet” was common parlance for the ARPANET (also called ARPA-Internet). This paper will use the latter definition.↩
Janet Abbate, Inventing the Internet (Cambridge: MIT Press, 1999), 189.↩
Katie Hafner and Matthew Lyon, Where Wizards Stay up Late: The Origins of the Internet (New York: Simon & Schuster, 1996).↩
Milton Mueller, Ruling the Root: Internet Governance and the Taming of Cyberspace (Cambridge, Mass: MIT Press, 2002).↩
For details on DNS hierarchy, see Appendix A. For definitions, see Appendix B.↩
Byung-Keum Kim, Internationalizing the Internet: The Co-Evolution of Influence and Technology (Cheltenham, UK: Edward Elgar, 2005), 7.↩
Langdon Winner, The Whale and the Reactor: A Search for Limits in an Age of High Technology (Chicago: University of Chicago Press, 1986), 20.↩
Emails will be cited as Surname, “Subject line” Mailing-list MM/DD/YYYY.↩
Stacy, “amusing” Namedroppers 7/22/1985.↩
Abbate, Inventing the Internet, 189.↩
For example see Arbour, “ARPANET Hosts Update” 10/8/1982. NIC Naming & Addressing Documents 1972-1999 Box #2: X3578.2006 SRI ARC/NIC/NIC Services ad Activities/Naming and Addressing/Host Tables/1982 (hereafter NIC-N&AD-Box#: X3578.2006-ARC/NIC/NSAA/N&A/HT/Year).↩
Crispin, “INSUFFICIENT QUALITY CONTROL IN NIC HOST TABLE” 5/20/1983. NIC Naming & Addressing Documents 1973-1992 Box #1: X3578.2006 SRI ARC/NIC/NIC Services and Activities/Naming and Addressing/Email and Correspondence/Jan-Jun 1982 (hereafter: NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Year).↩
Fair, “The Plethora of Networks” in HUMAN-NETS Digest V7 #3, 1/6/1984. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1984.↩
Craig Partidge, “The Technical Development of Internet Email,” IEEE Annals of the History of Computing 30, no. 2 (2008): 11.↩
“Arpanaut” was a popular colloquial term for ARPANET users at this time.↩
Between different networks↩
For a detailed description of the DNS, see Appendix A.↩
Mockapetris, “The Domain Name System.” Proceedings of the IFIP 6.5 Working Conference, (May 1984): 11. NIC Naming & Addressing Documents 1972-1999 Box #2: X3578.2006 SRI ARC/NIC/NIC Services and Activities/Naming and Addressing/Naming Reprints and Articles/1984 (hereafter NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/NR&A/Year).↩
Feinler, ”Hostnames,” Meeting Notes with DCA 11/1981. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1981.↩
Postel & Su, “DRAFT RFC The Naming Convention for Internet User Applications,” 5/24/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Jun-82.↩
Kingston, “Comments on your draft” Namedroppers 2/25/1983.↩
Su, “Proposal Contribution” 3/15/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Jun-82.↩
For an explanation of the Request for Comments (RFC) system, see Appendix B: Glossary.↩
Postel, “namedroppers policy” Namedroppers 5/23/1983.↩
Postel & Su, “DRAFT RFC The Naming Convention for Internet User Applications,” 6/11/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Jun-82.↩
Hedrick, “domains” Namedroppers 11/2/1983.↩
This paper will distinguish domains, particularly top level domains, in uppercase italics. ↩
Feinler, “Meeting w/ Vint Cerf” Meeting Notes 8/27/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jul-Dec-82.↩
Horton, “re: Top Level Domain Names” 11/9/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jul-Dec-82.↩
Horton, “re: Top Level Domain Names” 11/8/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jul-Dec-82.↩
Taft, “Re: Domain Names” Namedroppers 11/2/1983.↩
Horton, “Re: choices of domains” Namedroppers 11/4/1983.↩
Kille, “Thoughts on Nameservers and Domains” Namedroppers 3/24/1983.↩
Cole, “Re: Domain names and mailbox names” Namedroppers 7/29/1983.↩
For example, while SOMETHING.LSE.AC.UK would be a valid domain name, UK.AC.LSE.SOMETHING would be the NRS version.↩
Cole, Robert. “Naming, Addressing and Directories in Open Systems.” UCL Technical Report TR-106, 4/1/1985.↩
Abbate, Inventing the Internet, 165-73.↩
Kirstein, Peter. “Final Report on the Project Message Services and Directory Development.” UCL Technical Report, TR-116, 1/1986.↩
Einar Stefferud 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), v.↩
Kirton, “IFIP work on directory service” Namedroppers 6/1/1983.↩
Feinler, Meeting Notes. 1983. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Sep-Dec-83.↩
Feinler, “Name Droppers Mtg” Meeting Notes, 12/9/1983. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Sep-Dec-83.↩
Maas, “Domain requirements / must country be toplevel domain?” Namedroppers 5/15/1984.↩
Kent, “Re: Domain Names” Namedroppers 11/2/1983.↩
Gilmore, “Perils of ignoring non-direct mail delivery” Namedroppers 2/10/1984.↩
Horton, “Re: choices of domains” Namedroppers 11/4/1983.↩
Horton, “Domain requirements” Namedroppers 5/13/1984.↩
Margulies, “A Rose by any other Name” Namedroppers 5/21/1984.↩
Postel, “Inter-Environment Name Service” Namedroppers 5/3/1984.↩
Horton, “Re: Draft of RFC on Requirement to be a Domain” Namedroppers 5/2/1984.↩
Horton, “choices of domains” Namedroppers 11/3/1983.↩
Jake Feinler, unpublished email message to author, 1 May 2010.↩
Feinler, “Naming Domains,” 1/4/1984. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1984.↩
Postel, “Draft RFC on Requirements to be a Domain” Namedroppers 4/30/1984.↩
Horton, “Re: Draft of RFC on Requirement to be a Domain” Namedroppers 5/2/1984.↩
Postel, “DRAFT – Domain Requirements – New Version” Namedroppers 5/11/1984.↩
Elman, “proposal for top level domains” Namedroppers 5/12/1984.↩
Stefferud, “Re: Domain requirements” Namedroppers 5/13/1984.↩
Postel, “re: comments on Domain Requirements” Namedroppers 5/20/1984.↩
NIC Report, 7/1984. NIC Contract Materials: NIC Monthly Status Reports Box #4: X3578.2006 SRI ARC/NIC/NIC Monthly Progress Reports/1984 (hereafter NIC-CM/MSRB#: X3578.2006-ARC/NIC/NMPR/Year).↩
Postel, “Domain Requirements DRAFT memo” Namedroppers 7/28/1984.↩
Postel & Mockapetris, “A Perspective on Name System Design” NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/NR&A/1985.↩
Vinton Cerf, “Requiem for the Arpanet,” in Proceedings of the Thirteenth Internet Engineering Task Force, ed. Phillip Gross and Karen Bowers (1989), 308.↩
Abbate, Inventing the Internet, 143.↩
Comments from Elizabeth Feinler to the author.↩
Feinler, “Domains, Name Servers, etc.” 6/11/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Jun-82.↩
Postel and Su, “The Naming Convention for Internet User Applications.” 5/31/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Jun-82.↩
Feinler, “SINS paper.” 8/27/1982. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jul-Dec-82.↩
Hedrick, “Re: Domain comments / toplevel admittance policy” Namedroppers, 11/10/1983.↩
Margulies, “Proposed top level domains” Namedroppers 5/14/1984.↩
Elman, “proposal for top level domains” Namedroppers 5/12/1984.↩
Postel & Reynolds, “RFC DRAFT Domain Requirements – Feinler Edits” 4/1984. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1984.↩
Postel, Jon and Joyce Reynolds, “Domain Requirements” Request for Comments 920, 10/1984 (Hereafter “Surname, RFC #.”).↩
NIC Report, 10/1984. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1984.↩
Postel, “Domain Registration Request – Domain Name = US” 10/18/1984.↩
This policy – or lack of specific rules for ccTLD delegation – persisted throughout the rest of the decade until the creation of INTERNIC in the early 1990s.↩
Netherlands .NL Application. 9/4/1986. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1986.↩
Partridge, “Wildcarding and Domains” Namedroppers, 10/29/1985.↩
Nedved, “Re: Wildcarding and Domains” Namedroppers, 10/29/1985.↩
Partridge, “Wildcards and RFC 882” Namedroppers, 12/5/1985.↩
Jake Feinler, unpublished email to author, 1 May 2010.↩
Nedved, “Re: the US domain” Namedroppers, 12/27/1986.↩
Nedved, “Re: the US domain” Namedroppers, 12/29/1986.↩
Kirkpatrick, “More domain-brain picking” Namedroppers, 3/18/1988.↩
Stahl, RFC 1032.↩
Lottor, “Re: More domain-brain picking” Namedroppers, 3/20/1988.↩
IANA WHOIS Service, 2010. www.iana.org.↩
Diehl, “two questions” Namedroppers 7/28/1988.↩
NIC Report, 12/1983. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1983.↩
Feinler, “DDN” Meeting Notes, 1986. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1986.↩
Feinler, “MILNET Transition” Meeting Notes 1986. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1986.↩
Braun, “The Domain Name System…” Namedroppers 6/5/1986.↩
Horton, “Domain Wars” 1/13/1987. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1987.↩
Harrenstein, “.ORG” 5/28/1987. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1988.↩
Partridge, “Properly Naming NICs” Namedroppers 7/24/1987.↩
Lottor, “Re: two questions” Namedroppers 7/26/1988.↩
Partridge, “crucifixion” Namedroppers 4/18/1988.↩
Postel, “DDN MGT Bulletin 32” Namedroppers 2/14/1987.↩
Mark Lottor, “Domain Name System Status,” in Proceedings of the Fourteenth Internet Engineering Task Force, ed. Phillip Gross and Karen Bowers (1989), 314.↩
Postel, “The US Domain” Namedroppers 2/27/1987.↩
Postel, “The US Domain” Namedroppers 10/7/1988.↩
Prindeville, “Re: Domain Names” Namedroppers 4/13/1987.↩
Paraghi, “Re: why promote .gov and the like at the top?” Namedroppers 4/21/1989.↩
Lottor, “Domain Name System Status,” 312.↩
Stahl, RFC 1032.↩
NIC Report, 9/1989. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1989.↩
NIC Report, 3/1990. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1990.↩
Nash, “TEXAS.GOV or GOV.TX.US” Namedroppers 5/14/1990.↩
St Johns, “Re: TEXAS.GOV or GOV.TX.US” Namedroppers 5/14/1990.↩
Prindeville, “Re: TEXAS.GOV or GOV.TX.US” Namedroppers 5/16/1990.↩
Goodfellow, “Re: why promote .gov and the like to the top?” Namedroppers 4/19/1989.↩
Crispin, “Re: why promote .gov and the like to the top?” Namedroppers 4/18/1989.↩
Horton, “Re: canadian site in .com?” Namedroppers 2/19/1987.↩
Carpenter, “CERN Registration Request” 3/15/1988. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1988.↩
Smart, “Re: Why Germany lies about the DE. Domain” Namedroppers 5/21/1990.↩
Roode, “Re: domain names” Namedroppers 10/30/1985.↩
Goodfellow, “Re: why promote .gov and the like to the top?” Namedroppers 4/20/1989.↩
Feinler, “The US Domain” Namedroppers 2/27/1987.↩
Melohn, “Re: Mailing to DEC Easynet” TCP-IP, 8/11/1987.↩
NIC Report, 8/1985. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1985.↩
Mark Lottor, “The Nic Domain Chart,” in Proceedings of the Eleventh Internet Engineering Task Force, ed. Phillip Gross and Karen Bowers (October 1988).↩
Louis Mamakos, “Domains,” in Proceedings of the Tenth Internet Engineering Task Force, ed. Gladys Reichlen and Allison Mankin (June 1988), 168.↩
Mike St. Johns, “Growth of the Internet,” in Proceedings of the Thirteenth Internet Engineering Task Force, ed. Phillip Gross and Karen Bowers (1989), 244.↩
Prindeville, “Re: Why Germany lies about the DE. domain” Namedroppers 5/22/1990.↩
Dennis Jennings et al., “Computer Networking for Scientists,” Science 231, no. 4741 (1986): 943-44.↩
Phillip Gross, “Chairman’s Message,” in Proceedings of the Thirteenth Internet Engineering Task Force, ed. Phillip Gross and Karen Bowers (1989), 3.↩
Huntting, “Why does DDN lie about the de domain?” Namedroppers 5/2/1990.↩
NIC Report, 4/1990. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1990.↩
Eckert, “Re: Why does DDN lie about the de domain?” Namedroppers 5/4/1990.↩
Eckert, “Re: Why Germany lies about the DE. domain” Namedroppers 5/18/1990.↩
Mathiesen, “Why Germany lies about the DE. domain” Namedroppers 5/18/1990.↩
Braun, “Re: Draft Policy Statements” 6/26/1990. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Jan-Aug-1990.↩
Cerf, RFC 1174, 2.↩
Wolff, “RFC1174” 9/18/1990. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Sep-Dec-1990.↩
Stefan Schill, “Networking in Czechoslovakia: Efforts and Results,” Computer Networks and ISDN Systems 19, no. 5 (November 1990): 188.↩
Beertema, “Forgotten nation” USENET: eunet.misc, 11/9/1990.↩
Sterba, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/31/1990.↩
Grandi, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/22/1990.↩
Naggum, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/23/1990.↩
Grandi, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/28/1990.↩
Jansen, “Secondary domains” USENET: eunet.misc, 11/15/1990.↩
Joint Network Team, “The Transition to OSI Standard Protocols.” 10/23/1984 CB(84)104. British National Archives ED 238/54.↩
Collinson, “Secondary domains” USENET: eunet.misc, 11/15/1990.↩
Westberg, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/30/1990.↩
Joint Network Team, “Network Executive Report” 12/15/1987 CB(87)112. British National Archives ED 238/45.↩
Horton, “Re: medical community (50-100 fanout)” Namedroppers 7/15/1986.↩
Wade, “Secondary domains” USENET: eunet.misc, 11/16/1990.↩
Naggum, “Re: CS top-level domain and its impact on the UK?” Namedroppers 7/29/1990.↩
Davis, “Re: Domains created in October 1990” Namedroppers 11/5/1990.↩
Woodburn, “Domains Registered in October 1990” Namedroppers 11/6/1990.↩
NIC Report, 11/1990. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1990.↩
NIC Report, 12/1989. NIC-CM/MSRB#4: X3578.2006-ARC/NIC/NMPR/1989.↩
NIC Report, 11/1990.↩
Hedrick, “Re: domains” Namedroppers 11/3/1983.↩
Kirkpatrick, “[joaquin@NISC.SRI.COM (Jose Garcia-Luna) : roll back]” 12/11/1990. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/Sep-Dec-1990.↩
Phillip Gross, “Chairman’s Message,” in Proceedings of the Eighteenth Internet Engineering Task Force, ed. Phillip Gross and Gregory Vaudreuil (July-August 1990), 2.↩
Garcia-Luna, “roll back” 12/10/1990. NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/E&C/1990.↩
Williamson and Nobile, RFC 1261.↩
Jake Feinler, unpublished email message to author, 1 May 2010.↩
Postel & Mockapetris, “A Perspective on Name System Design” NIC-N&AD-Box#1: X3578.2006-ARC/NIC/NSAA/N&A/NR&A/1985.↩
Kim, Internationalizing the Internet: The Co-Evolution of Influence and Technology, 128. This is the latest date given in the secondary literature. Most sources place ISO-3166 adoption sometime after 1985 or 1986.↩