The conclusion in this area was that the current “user@host” mailbox identifier should be extended to “firstname.lastname@example.org” where “domain” could be a hierarchy of domains.
– J. Postel; Computer Mail Meeting Notes, RFC 805; 8 Feb 1982.
Alphabetic host names were introduced on the ARPANET shortly after its creation, and greatly increased usability since alphabetic names are much easier to remember than semantically meaningless numeric addresses. Host names were also useful for development of network-aware computer programs, since they could reference a constant host name without concern about changes to the physical address due to network alterations. Of course, the infrastructure of the underlying network was still based on numeric addresses, so each site maintained a “HOSTS.TXT” file that provided a mapping between host names and network addresses in a set of simple text records that could be easily read by a person or program.
It wasn’t long before people realized that keeping multiple copies of the hosts file was inefficient and error-prone. Starting with a formal proposal for centralization in Host Names On-line, RFC 606, in December, 1973, proceeding through agreement in Host Names On-Line, RFC 608, and further discussions in Comments on On-Line Host Name Service, RFC 623, it was settled by March, 1974 with On Line Hostnames Service, RFC 625, that the Stanford Research Institute Network Information Center (NIC) would serve as the official source of the master hosts file.
This centralized system worked well for about a decade, approximately 1973 to 1983. However, by the early 1980’s the disadvantages of centralized management of a large amount of dynamic data were becoming apparent. The hosts file was becoming larger, the rate of change was growing as the network expanded, more hosts were downloading the entire file nightly, and there were always errors that were then propagated network-wide. Change was required, but a spark was needed.
As described in Computer Mail Meeting Notes, RFC 805, it was initially the need for a real-world solution to the complexity of email relaying that triggered the development of the domain concept. A group of ARPANET researchers, principles, and related parties held a meeting in January, 1982, to discuss a solution for email relaying. As described on the email addresses page, email was often originally sent from site to site to its destination along a path of systems, and might need to go through a half a dozen or more links that would connect at certain times of the day. For example, the following actual communication path shows individual systems separated by “!”, with the destination user named “grg” tagged on at the end.
To send an email to someone, you had to first be a human router and specify a valid path to the destination as part of the address. If you didn’t know a valid route, the software couldn’t help you. In order to solve this problem, domain names were created to provide each person with one address regardless of where email was sent from. As RFC 805 put it, “The hierarchical domain type naming differs from source routing in that the former gives absolute addressing while the latter gives relative addressing”.
RFC 805 outlines many of the basic principles of the eventual domain name system, including the need for top level domains to provide a starting point for delegation of queries, the need for second level domains to be unique — and therefore the requirement for a registrar type of administration, and the recognition that distribution of individual name servers responsible for each domain would provide administration and maintenance advantages.
Within the year, the concept was developed through a series of communications. In March, the hosts table definition was updated with DoD Internet Host Table Specification, RFC 810, and NIC’s introduction of a server function to provide individual host name / address translations was described in Hostnames Server, RFC 811, both documents including the domain concept. In August, The Domain Naming Convention for Internet User Applications, RFC 819, provided an excellent overview of the concept. And then, in October, the full concept of a distributed system of name servers, each serving its local domain, was described in A Distributed System for Internet Name Service, RFC 830, providing the main architectural outlines of the system still in use today.
By the following November, 1983, the concept and schedule were developed and published in The Domain Names Plan and Schedule, RFC 881, Domain Names — Concepts And Facilities, RFC 882, and Domain Names — Implementation And Specification, RFC 883.
Some of the technical discussion involved in developing the DNS was carried out on the namedroppers list.
BIND. Because the DNS is such a fundamental part of the operation of the Internet network, the software that runs it must be nearly fault free, easily upgraded when a bug is found, and completely trusted by the Internet community — in other words, free open source software.
The application that runs almost every DNS server on the Internet is called BIND, for Berkeley Internet Name Domain, first developed as a graduate student project at the University of California at Berkeley, and maintained through version 4.8.3 by the university’s Computer Systems Research Group (CSRG). The initial BIND development team consisted of Mark Painter, David Riggle, Douglas Terry, and Songnian Zhou. Later work was done by Ralph Campbell and Kevin Dunlap, and others that contributed include Jim Bloom, Smoot Carl-Mitchell, Doug Kingston, Mike Muuss, Craig Partridge, and Mike Schwartz. Application maintenance was done by Mike Karels and O. Kure.
Versions 4.9 and 4.9.1 of BIND were released by then the number two computer company, Digital Equipment Corporation. The lead developer was Paul Vixie, with assistance from Paul Albitz, Phil Almquist, Fuat Baran, Alan Barrett, Bryan Beecher, Andy Cherenson, Robert Elz, Art Harkin, Anant Kumar, Don Lewis, Tom Limoncelli, Berthold Paffrath, Andrew Partan, Win Treese, and Christophe Wolfhugel. After Vixie left to establish Vixie Enterprises, he sponsored the development of BIND Version 4.9.2, and became the application’s principal architect.
Versions 4.9.3 on have been developed and maintained by the Internet Systems Consortium. A major architectural update called Version 8 was co-developed by Bob Halley and Paul Vixie and released in May 1997. Another major architectural rewrite called Version 9 with enhanced security support was developed and released in the year 2000.