Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
In Search of Jeffersons Moose Chapter 10

In Search of Jeffersons Moose Chapter 10

Ratings: (0)|Views: 354|Likes:
Published by David Post
Chapter 10 of "In Search of Jefferson's Moose" is the story of ICANN and the Internet's domain name system -- and about what each tells us about what "law" and "governance" are going to look like in the Internet Age.
Chapter 10 of "In Search of Jefferson's Moose" is the story of ICANN and the Internet's domain name system -- and about what each tells us about what "law" and "governance" are going to look like in the Internet Age.

More info:

Published by: David Post on Jul 09, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Nothing better illustrates the new and complex nature of the relationship betweencode-making and lawmaking and Internet governance at the bottom of the protocolstack than the story of ICANN—the Internet Corporation for Assigned Names andNumbers.ICANN was born in October 1998, its birth the culmination of the first (butprobably not the last) crisis in “Internet governance.” To understand the crisis, andICANN’s role in it, we need to take a closer look at the way that the Internet Proto-cols manage the assignment of 
on the inter-network—the so-called DomainName System, or DNS.
TCP/IP networks rely, as we saw earlier, entirely upon
IP addresses tomove messages from one place to another on the network. It is the one irreduciblerequirement for communication over the Internet: every communication mustcontain the recipient’s IP address in order for the network to do its job—its
  job—of routing it properly to its destination.But as everyone who uses the Internet is well aware, the network manages toroute messages based on machine
rather than numbers; you can address amessage to “temple.edu,” or “eff.org,” or “google.com,” rather than to or or, and the message will, in fact, be routed to the rightmachine. How does that work? How does the network determine which of its morethan 500 million machines bears the name “temple.edu,” or “eff.org,” or “google.com”? How does it ensure that there’s only one machine bearing each of those
names? How does it find the correct IP Address for that machine, so that a messageaddressed to it by name alone can be properly delivered?The ability to use names instead of numbers makes the network much easier touse, of course, given how much easier it is to remember names than to remembernumbers. The designers of the early versions of the TCP/IP protocols recognizedthis simple and obvious fact, and, after a relatively short period during which net- work users actually had to enter numerical addresses for all messages, by the mid-1970s they had devised a naming system that was as simple and straightforwardas you can imagine. A single database file—known as “hosts.txt,”—would list thename, and corresponding numerical IP Address, for each machine on the network:
. . .. . .ISI49UCLA11UniversityofUtah121DoD-009232. . .. . .Elmer63. . .. . . .
It was exactly like a simple telephone book—names associated with numbers. Inthe network’s early days, of course, it was only a couple of dozen, then a couple of hundred, lines long.Every machine on the inter-network would have its own copy of the “hosts.txt”file. Then, when a message was sent from anywhere to “UCLA,” the address fieldcould read “UCLA”; the sender’s machine would then perform what engineers calla “lookup”—it would search through its copy of the hosts.txt file to find the match-ing string (“UCLA”), insert the correct numerical address for that machine into themessage (“11”), and off the message would go.To make this system work, someone had to maintain a master copy of the hosts.txt file—the Keeper of the Names and Numbers. That job fell to Jon Postel, then agraduate student in computer science at UCLA (and subsequently a member of thefaculty at the Information Sciences Institute at the University of Southern Califor-nia). If you wanted to hook your machine up to this network, you had to sign up withPostel; he’d give you a name and a number and insert your entry into the hosts.txtfile. Every so often, Postel would send out a fresh copy of the file to everybody on thenetwork, so that they each had an up-to-date listing.
It was as simple as could be, and it worked perfectly well—but only for a short while. As the network started growing, the engineers quickly realized that this system wouldn’t scale. It couldn’t handle 500 million machines—not (literally) in a million years. A 500-million-line hosts.txt file is a very big file—just imagine if 
messagesent out from every machine on today’s Internet required a lookup in a database 500million entries long. Computers are fast—but they’re not fast enough for that; even at1 million operations a second, that’s 500 seconds—more than eight minutes—of pro-cessing for every single message going out over the network. I connect to the Internetover a Temple University host computer that probably processes 10 million messages aday—that’s 4 billion seconds (about 125 years) worth of processing for one day’s worthof messages. Exponential growth of a network designed like this would mean exponen-tial growth of the size the hosts.txt file, and that exponentially growing file would haveto be sent out more and more frequently (to keep it up-to-date on all machines), andto an exponentially increasing number of machines, and every message sent by any of those (exponentially growing) number of machines would require a lookup throughthis exponentially growing hosts.txt file to find the proper IP Address for the recipient.It wouldn’t work. In 1983 Postel and several colleagues proposed a series of Internet Standards defining a new naming scheme—the Domain Name System, which, with some modifications, persists today. The new system had two signifi-cant new features: (1) names would be
hierarchically nested
within “domains,”and (2) the databases associating names and IP Addresses would be
 around the network.Hierarchical nesting works as follows. The space of all usable names is dividedup into “domains.” At the top are the
domains (or TLDs). Postel’s initialspecification called for seven so-called “generic” TLDs—“EDU,” “ORG,” “COM,”“MIL,” “NET,” “GOV,” and “INT”—as well as top-level domains representing indi- vidual countries (the “country-code TLDs,” or ccTLDs) that would have names inaccordance with the list prepared by the International Standards Organization—“JP” for Japan, “DE” for Germany, “US” for the United States, etc.).Each top-level domain can contain any number of 2d-level (second-level) domains.So, for instance, the EDU top-level domain contains a 2d-level domain named“temple”—conventionally represented as “temple.edu,” the convention being thatdomain names are read from right to left, the top-level ORG domain contains a 2d-level domain named “EFF” (EFF.org)—the top-level COM domain contains a 2d-leveldomain named “google” (google.com), etc. (see fig. 10.1). Each 2d-level domain cancontain any number of named 3d-level ( third-level) domains; so, for instance, “www”is the name of a third-level domain within the “temple” 2d-level domain within the“EDU” top-level domain (www.temple.edu), “download” is a 3d-level name withinthe “google” 2d-level domain within the “COM” top-level domain (download.google.com), “about” is a third-level domain within the “EFF” 2d-level domain within the“ORG” top-level domain (about.eff.org). And so on (up to 127 levels deep).

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->