>Appendix A. Appendices</
A> Reference Information</
A>Bibliography (and Suggested Reading)</
A>A.1.1. A Brief History of the <
SPAN>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 RFCs 882 and
883. From 1984 to 1987, the ARPAnet (the precursor to today's
Internet) became a testbed of experimentation for developing the
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 <
SPAN>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 <
SPAN> server for Unix machines, the Berkeley Internet
>) 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 <
SPAN> 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 <
SPANproject 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 <
SPANto 1987. Many other people also contributed to <
SPANduring that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
Mike Muuss, Jim Bloom and Mike Schwartz. <
SPAN> maintenance was subsequently
handled by Mike Karels and O. Kure.</
P> versions 4.9 and 4.9.1 were released by Digital Equipment
Corporation (now Compaq Computer Corporation). Paul Vixie, then
a DEC employee, became <
SPAN>'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.</
P> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
> versions from 4.9.3 onward have been developed and maintained
by the Internet Software Consortium with support being provided
Paul Vixie released the first production-ready version of <
SPAN> development work is made possible today by the sponsorship
of several corporations, and by the tireless work efforts of numerous
NAME="historical_dns_information" > Reference Information</
A>A.2.1. IPv6 addresses (AAAA)</
A>IPv6 addresses are 128-bit identifiers for interfaces and
sets of interfaces which were introduced in the <
SPANscalable Internet routing. There are three types of addresses: <
SPANan identifier for a single interface; <
SPANan identifier for a set of interfaces; and <
SPANan identifier for a set of interfaces. Here we describe the global
Unicast address scheme. For more information, see RFC 2374.</
P>The aggregatable global Unicast address format is as follows:</
P><------ Public Topology
><-Site Topology-></
P><------ Interface Identifier ------></
P>Top-Level Aggregation Identifier</
P>Reserved for future use</
P>Next-Level Aggregation Identifier</
P>Site-Level Aggregation Identifier</
Pupstream provider or ISP, and (roughly) corresponds to the IPv4 <
SPANof the address range. The <
SPANwhere you can subnet this space, much the same as subnetting an
IPv4 /16 network into /24 subnets. The <
SPANthe address of an individual interface on a given network. (With
IPv6, addresses belong to interfaces rather than machines.)</
P>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).</
P>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:</
P>2001:4f8:201:9:a00:20ff:fe81:2b32</
B>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.</
P>A.3. Bibliography (and Suggested Reading)</
A>A.3.1. Request for Comments (RFCs)</
A>Specification documents for the Internet protocol suite, including
>, 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
the number of the RFC). RFCs are also available via the Web at
>Mail Routing and the Domain System</
ISTYLE="margin-left=0.5in" >Domain Names — Concepts and Facilities</
ISTYLE="margin-left=0.5in" >Domain Names — Implementation and
STYLE="margin-left=0.5in" NAME="proposed_standards" >Clarifications to the <
SPANSTYLE="margin-left=0.5in" >Negative Caching of <
SPANSTYLE="margin-left=0.5in" >Incremental Zone Transfer in <
SPANSTYLE="margin-left=0.5in" >A Mechanism for Prompt Notification of Zone Changes</
ISTYLE="margin-left=0.5in" >Dynamic Updates in the Domain Name System</
ISTYLE="margin-left=0.5in" >D. Eastlake, 3rd, </
SPAN>Secret Key Transaction Authentication for <
SPANSTYLE="margin-left=0.5in" >Proposed Standards Still Under Development</
A> Extensions to support IP version 6</
ISTYLE="margin-left=0.5in" >Domain Name System Security Extensions</
ISTYLE="margin-left=0.5in" >Secure Domain Name System Dynamic Update</
ISTYLE="margin-left=0.5in" >Other Important RFCs About <
SPAN>A Security Problem and Proposed Correction With Widely Deployed <
SPANSTYLE="margin-left=0.5in" > Implementation Errors and Suggested Fixes</
ISTYLE="margin-left=0.5in" >Serial Number Arithmetic</
ISTYLE="margin-left=0.5in" >Resource Record Types</
A>and P. Mockapetris</
SPANSTYLE="margin-left=0.5in" > NSAP Resource Records</
ISTYLE="margin-left=0.5in" >Resolution of Uniform Resource Identifiers using
the Domain Name System</
ISTYLE="margin-left=0.5in" >A Means for Expressing Location Information in the Domain
STYLE="margin-left=0.5in" > RR for Specifying the Location of
STYLE="margin-left=0.5in" >Using the Internet <
SPANConformant Global Address Mapping</
ISTYLE="margin-left=0.5in" >Key Exchange Delegation Record for the <
SPANSTYLE="margin-left=0.5in" > Encoding of Network Names and Other Types</
ISTYLE="margin-left=0.5in" >Requirements for Internet Hosts - Application and Support</
ISTYLE="margin-left=0.5in" >Domain Name System Structure and Delegation</
ISTYLE="margin-left=0.5in" STYLE="margin-left=0.5in" > Data File Configuration Errors</
ISTYLE="margin-left=0.5in" > Operational and Configuration Errors</
ISTYLE="margin-left=0.5in" >Operational Criteria for Root Name Servers.</
ISTYLE="margin-left=0.5in" > Aliases for Network Services.</
ISTYLE="margin-left=0.5in" >Using the Domain Name System To Store Arbitrary String Attributes</
ISTYLE="margin-left=0.5in" STYLE="margin-left=0.5in" > Support for Load Balancing</
ISTYLE="margin-left=0.5in" >A Legal Basis for Domain Name Allocation</
ISTYLE="margin-left=0.5in" >Domain Names and Company Name Retrieval</
ISTYLE="margin-left=0.5in" >A Convention For Using Legal Names as Domain Names</
ISTYLE="margin-left=0.5in" >Obsolete and Unimplemented Experimental RRs</
A> Encoding of Geographical
STYLE="margin-left=0.5in" >A.3.2. Internet Drafts</
A>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.
>A.3.3. Other Documents About <
SPANSTYLE="margin-left=0.5in" SUMMARY="Footer navigation table"