TreeWalk DNS

Home

Support

FAQ

Downloads

Forums

XP/2K+ Tips

Site Map

Content

BIND 9.3.2 - Appendix A.

Administrator Reference Manual
· Appendices

Acknowledgments

A Brief History of the DNS and BIND

Although the "official" beginning of the Domain Name System occurred in 1984 with the publication of RFC 920, the core of the new system was described in 1983 in RFC 882 and RFC 883. From 1984 to 1987, the ARPAnet (the precursor to today's Internet) became a testbed of experimentation for developing the new naming/addressing scheme in an rapidly expanding, operational network environment. New RFCs were written and published in 1987 that modified the original documents to incorporate improvements based on the working model. RFC 1034, "Domain Names-Concepts and Facilities", and RFC 1035, "Domain Names-Implementation and Specification" were published and became the standards upon which all DNS implementations are built.

The first working domain name server, called "Jeeves", was written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 machines located at the University of Southern California's Information Sciences Institute (USC-ISI) and SRI International's Network Information Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet Name Domain (BIND) package, was written soon after by a group of graduate students at the University of California at Berkeley under a grant from the US Defense Advanced Research Projects Administration (DARPA). Versions of BIND through 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the initial BIND project team. After that, additional work on the software package was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation employee on loan to the CSRG, worked on BIND for 2 years, from 1985 to 1987. Many other people also contributed to BIND development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently handled by Mike Karels and O. Kure.

BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then a DEC employee, became BIND's primary caretaker. Paul was assisted by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and others.

BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul Vixie became BIND's principal architect/programmer.

BIND versions from 4.9.3 onward have been developed and maintained by the Internet Software Consortium with support being provided by ISC's sponsors. As co-architects/programmers, Bob Halley and Paul Vixie released the first production-ready version of BIND version 8 in May 1997.

BIND development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous individuals.

General DNS Reference Information

IPv6 addresses (AAAA)

IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces which were introduced in the DNS to facilitate scalable Internet routing. There are three types of addresses: Unicast, an identifier for a single interface; Anycast, an identifier for a set of interfaces; and Multicast, an identifier for a set of interfaces. Here we describe the global Unicast address scheme. For more information, see RFC 2374.

The aggregatable global Unicast address format is as follows:

3	13	8	24	16	64 bits
FP	TLA ID	RES	NLA ID	SLA ID	Interface ID
<	Public	Topology	>
				< Site Topology >
					< Interface Identifier >

Where

FP	=	Format Prefix (001)
TLA ID	=	Top-Level Aggregation Identifier
RES	=	Reserved for future use
NLA ID	=	Next-Level Aggregation Identifier
SLA ID	=	Site-Level Aggregation Identifier
INTERFACE ID	=	Interface Identifier

The Public Topology is provided by the upstream provider or ISP, and (roughly) corresponds to the IPv4 network section of the address range. The Site Topology is where you can subnet this space, much the same as subnetting an IPv4 /16 network into /24 subnets. The Interface Identifier is the address of an individual interface on a given network. (With IPv6, addresses belong to interfaces rather than machines.)

The subnetting capability of IPv6 is much more flexible than that of IPv4: subnetting can now be carried out on bit boundaries, in much the same way as Classless InterDomain Routing (CIDR).

The Interface Identifier must be unique on that network. On ethernet networks, one way to ensure this is to set the address to the first three bytes of the hardware address, "FFFE", then the last three bytes of the hardware address. The lowest significant bit of the first byte should then be complemented. Addresses are written as 32-bit blocks separated with a colon, and leading zeros of a block may be omitted, for example:

2001:db8:201:9:a00:20ff:fe81:2b32

IPv6 address specifications are likely to contain long strings of zeros, so the architects have included a shorthand for specifying them. The double colon (`::') indicates the longest possible string of zeros that can fit, and can be used only once in an address.

Bibliography (and Suggested Reading)

Request for Comments (RFCs)

Specification documents for the Internet protocol suite, including the DNS, are published as part of the Request for Comments (RFCs) series of technical notes. The standards themselves are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be obtained online via FTP at ftp://www.isi.edu/in-notes/RFCxxx.txt (where xxx is the number of the RFC). RFCs are also available via the Web at http://www.ietf.org/rfc/.

Bibliography

Standards

[RFC 974] C. Partridge. Mail Routing and the Domain System. January 1986.

[RFC 1034] P.V. Mockapetris. Domain Names — Concepts and Facilities. November 1987.

[RFC 1035] P. V. Mockapetris. Domain Names — Implementation and Specification. November 1987.

Proposed Standards

[RFC 2181] R., R. Bush Elz. Clarifications to the DNS Specification. July 1997.

[RFC 2308] M. Andrews. Negative Caching of DNS Queries. March 1998.

[RFC 1995] M. Ohta. Incremental Zone Transfer in DNS. August 1996.

[RFC 1996] P. Vixie. A Mechanism for Prompt Notification of Zone Changes. August 1996.

[RFC 2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System. April 1997.

[RFC 2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington. Secret Key Transaction Authentication for DNS (TSIG). May 2000.

Proposed Standards Still Under Development

Note: the following list of RFCs are undergoing major revision by the IETF.

[RFC 1886] S. Thomson and C. Huitema. DNS Extensions to support IP version 6. December 1995.

[RFC 2065] D. Eastlake, 3rd and C. Kaufman. Domain Name System Security Extensions. January 1997.

[RFC 2137] D. Eastlake, 3rd. Secure Domain Name System Dynamic Update. April 1997.

Other Important RFCs About DNS Implementation

[RFC 1535] E. Gavron. A Security Problem and Proposed Correction With Widely Deployed DNS Software.. October 1993.

[RFC 1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller. Common DNS Implementation Errors and Suggested Fixes. October 1993.

[RFC 1982] R. Elz and R. Bush. Serial Number Arithmetic. August 1996.

Resource Record Types

[RFC 1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris. New DNS RR Definitions. October 1990.

[RFC 1706] B. Manning and R. Colella. DNS NSAP Resource Records. October 1994.

[RFC 2168] R. Daniel and M. Mealling. Resolution of Uniform Resource Identifiers using the Domain Name System. June 1997.

[RFC 1876] C. Davis, P. Vixie, T., and I. Dickinson. A Means for Expressing Location Information in the Domain Name System. January 1996.

[RFC 2052] A. Gulbrandsen and P. Vixie. A DNS RR for Specifying the Location of Services.. October 1996.

[RFC 2163] A. Allocchio. Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping. January 1998.

[RFC 2230] R. Atkinson. Key Exchange Delegation Record for the DNS. October 1997.

DNS and the Internet

[RFC 1101] P. V. Mockapetris. DNS Encoding of Network Names and Other Types. April 1989.

[RFC 1123] Braden. Requirements for Internet Hosts - Application and Support. October 1989.

[RFC 1591] J. Postel. Domain Name System Structure and Delegation. March 1994.

[RFC 2317] H. Eidnes, G. de Groot, and P. Vixie. Classless IN-ADDR.ARPA Delegation. March 1998.

DNS Operations

[RFC 1537] P. Beertema. Common DNS Data File Configuration Errors. October 1993.

[RFC 1912] D. Barr. Common DNS Operational and Configuration Errors. February 1996.

[RFC 2010] B. Manning and P. Vixie. Operational Criteria for Root Name Servers.. October 1996.

[RFC 2219] M. Hamilton and R. Wright. Use of DNS Aliases for Network Services.. October 1997.

Other DNS-related RFCs

Note: the following list of RFCs, although DNS-related, are not concerned with implementing software.

[RFC 1464] R. Rosenbaum. Using the Domain Name System To Store Arbitrary String Attributes. May 1993.

[RFC 1713] A. Romao. Tools for DNS Debugging. November 1994.

[RFC 1794] T. Brisco. DNS Support for Load Balancing. April 1995.

[RFC 2240] O. Vaughan. A Legal Basis for Domain Name Allocation. November 1997.

[RFC 2345] J. Klensin, T. Wolf, and G. Oglesby. Domain Names and Company Name Retrieval. May 1998.

[RFC 2352] O. Vaughan. A Convention For Using Legal Names as Domain Names. May 1998.

Obsolete and Unimplemented Experimental RRs

[RFC 1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni. DNS Encoding of Geographical Location. November 1994.

Internet Drafts

Internet Drafts (IDs) are rough-draft working documents of the Internet Engineering Task Force. They are, in essence, RFCs in the preliminary stages of development. Implementors are cautioned not to regard IDs as archival, and they should not be quoted or cited in any formal documents unless accompanied by the disclaimer that they are "works in progress." IDs have a lifespan of six months after which they are deleted unless updated by their authors.