UNIX System Administration Handbook - Evi Nemeth [236]
16.2 THE HISTORY OF DNS
In the good old days, the mapping between hostnames and addresses was kept in a single text file that was managed centrally and distributed to all the hosts on the ARPANET. Hostnames were not hierarchical, and the procedure for naming a computer included verifying that no one else in the world had taken the name you wanted. Updates consumed a large portion of the ARPANET’s bandwidth, and the file was constantly out of date.
It soon became clear that although a static host table was reasonable for a small network, it was inadequate for the large and growing ARPANET. DNS solves the problems of a static table by using two key concepts: hierarchical hostnames and distributed responsibility. DNS was formally specified by Paul Mockapetris in RFCs 882 and 883 (1983) and updated in RFCs 1034 and 1035 (1987). Paul also wrote an early non-UNIX implementation.
The original UNIX work was done by four graduate students at Berkeley (Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou) in 1984. It was then picked up by Ralph Campbell of Berkeley’s Computer Systems Research Group, who started gluing it into BSD. In 1985, Kevin Dunlap, a DEC engineer on loan to Berkeley, took over the project and produced BIND, the Berkeley Internet Name Domain system. Mike Karels, Phil Almquist, and Paul Vixie have maintained BIND over the years. It is shipped with most vendors’ UNIX systems and is also available from www.isc.org.
ISC, the Internet Software Consortium, is a nonprofit organization that maintains several crucial pieces of Internet software, including BIND. Paul Vixie currently maintains the BIND 8 code tree on ISC’s behalf with help from folks on the bind-workers mailing list. ISC is developing BIND 9 with funding from several vendors, government agencies, and other organizations.
ISC also provides various types of support for these products, including help with configuration and even custom programming. These services are a boon for sites that must have a support contract before they can use open source software. Several companies use service contracts as a way to contribute to the ISC—they buy expensive contracts but never call for help.
RFCs 1034 and 1035 are still considered the baseline specification for DNS, but more than 30 other RFCs have superseded and elaborated upon various aspects of the protocol and data records over the last decade (see the list at the end of this chapter). Currently, no single standard or RFC brings all the pieces together in one place. Historically, DNS has more or less been defined as “what BIND implements,” though this is becoming less accurate as other DNS servers emerge.
Although DNS has been implemented on non-UNIX operating systems, this book discusses only BIND. Nortel ported BIND to Windows NT and contributed the port back to ISC; since then, BIND version 8.2 has been available for NT, too. Thanks to the standardization of the DNS protocol, UNIX and non-UNIX DNS implementations can interoperate and share data. Many sites run UNIX servers to provide DNS service to their Windows desktops; the combination works well.
16.3 WHO NEEDS DNS?
DNS defines:
• A hierarchical namespace for hosts and IP addresses
• A host table implemented as a distributed database
• A “resolver” – library routines that query this database
• Improved routing for email
• A mechanism for finding services on a network
• A protocol for exchanging naming information
To be full citizens of the Internet, sites need DNS. Maintaining a local /etc/hosts file with mappings for every host your users might ever want to contact is not feasible.
Each site maintains one or more pieces of the distributed database that makes up the world-wide DNS system. Your piece of the database consists of two or more text files that contain records for each of your hosts. Each record is a single line consisting of a name (usually a hostname), a record