A word on “the Internet,” and on “internets” in general, is in order. In print, the difference between the two seems slight: one is always capitalized, one isn’t. The distinction between their meanings, however, is significant. The Internet, with a capital “I,” refers to the network that began its life as the ARPANET and continues today as, roughly, the confederation of all TCP/IP networks directly or indirectly connected to commercial U.S. backbones. Seen up close, it’s actually quite a few different networks—commercial TCP/IP backbones, corporate and U.S. government TCP/IP networks, and TCP/IP networks in other countries—interconnected by high-speed digital circuits.
A lowercase internet, on the other hand, is simply any network made up of multiple smaller networks using the same internetworking protocols. An internet (little “i”) isn’t necessarily connected to the Internet (big “I”), nor does it necessarily use TCP/IP as its internetworking protocol. There are isolated corporate internets, and there are Xerox XNS-based internets and DECnet-based internets.
The new term “intranet” is really just a marketing term for a TCP/IP-based “little i” internet, used to emphasize the use of technologies developed and introduced on the Internet within a company’s internal corporate network. An “extranet,” on the other hand, is a TCP/IP-based internet that connects partner companies, or a company to its distributors, suppliers, and customers.
the 1970s, the ARPANET was a small, friendly community of a few
hundred hosts. A single file,
contained a name-to-address mapping for every host connected to the
ARPANET. The familiar Unix host table,
/etc/hosts, was compiled from
HOSTS.TXT (mostly by deleting fields Unix
was maintained by SRI’s Network Information
Center (dubbed “the NIC”) and distributed from
a single host, SRI-NIC. ARPANET administrators typically
emailed their changes to the NIC and periodically
ftped to SRI-NIC and grabbed
HOSTS.TXT file. Their changes were
compiled into a new
HOSTS.TXT file once or twice
a week. As the ARPANET grew, however, this scheme became unworkable.
The size of
HOSTS.TXT grew in proportion to the
growth in the number of ARPANET hosts. Moreover, the traffic
generated by the update process increased even faster: every
additional host meant not only another line in
HOSTS.TXT, but potentially another host updating
When the ARPANET moved to the TCP/IP protocols, the population of the
network exploded. Now there was a host of problems with
HOSTS.TXT could have the same name.
However, while the NIC could assign addresses in a way that
guaranteed uniqueness, it had no authority over hostnames. There was
nothing to prevent someone from adding a host with a conflicting name
and breaking the whole scheme. Adding a host with the same name as a
major mail hub, for example, could disrupt mail service to much of
Maintaining consistency of the file across
an expanding network became harder and harder. By the time a new
HOSTS.TXT file could reach the farthest shores
of the enlarged ARPANET, a host across the network may have changed
addresses or a new host may have sprung up.
The essential problem was that the
mechanism didn’t scale well. Ironically, the success of the
ARPANET as an experiment led to the failure and obsolescence of
The ARPANET’s governing bodies chartered an investigation into
a successor for
HOSTS.TXT. Their goal was to
create a system that solved the problems inherent in a unified host
table system. The new system should allow local administration of
data, yet make that data globally available. The decentralization of
administration would eliminate the single-host bottleneck and relieve
the traffic problem. And local management would make the task of
keeping data up-to-date much easier. It should use a hierarchical
namespace to name hosts. This would ensure the uniqueness of names.
Paul Mockapetris, then of USC’s Information Sciences Institute, was responsible for designing the architecture of the new system. In 1984, he released RFCs 882 and 883, which describe the Domain Name System. These RFCs were superseded by RFCs 1034 and 1035, the current specifications of the Domain Name System. RFCs 1034 and 1035 have since been augmented by many other RFCs, which describe potential DNS security problems, implementation problems, administrative gotchas, mechanisms for dynamically updating name servers and for securing zone data, and more.
 SRI is the former Stanford Research Institute in Menlo Park, California. SRI conducts research into many different areas, including computer networking.
 RFCs are Request for Comments documents, part of the relatively informal procedure for introducing new technology on the Internet. RFCs are usually freely distributed and contain fairly technical descriptions of the technology, often intended for implementers.