Bv9ARM.ch09.html revision 56f1285ca5d97d3205b74c32dc4de1ea7b69fea1
<HTML
><HEAD
><TITLE
>Appendices</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.41"><LINK
REL="HOME"
HREF="Bv9ARM.html"><LINK
REL="PREVIOUS"
TITLE="Troubleshooting"
HREF="Bv9ARM.ch08.html"></HEAD
><BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="Bv9ARM.ch08.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
> </TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="appendix"
><H1
><A
NAME="ch09"
>Appendix A. Appendices</A
></H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>A.1. <A
HREF="Bv9ARM.ch09.html#AEN3950"
>Acknowledgements</A
></DT
><DT
>A.2. <A
HREF="Bv9ARM.ch09.html#historical_dns_information"
>Historical <SPAN
CLASS="acronym"
>DNS</SPAN
> Information</A
></DT
><DT
>A.3. <A
HREF="Bv9ARM.ch09.html#AEN3991"
>General <SPAN
CLASS="acronym"
>DNS</SPAN
> Reference Information</A
></DT
><DT
>A.4. <A
HREF="Bv9ARM.ch09.html#bibliography"
>Bibliography (and Suggested Reading)</A
></DT
><DT
>A.5. <A
HREF="Bv9ARM.ch09.html#statsfile"
>Format of statistics file</A
></DT
></DL
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN3950"
>A.1. Acknowledgements</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN3952"
>A.1.1. A Brief History of the <SPAN
CLASS="acronym"
>DNS</SPAN
> and <SPAN
CLASS="acronym"
>BIND</SPAN
></A
></H2
><P
>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
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 <SPAN
CLASS="acronym"
>DNS</SPAN
> implementations are
built.
</P
><P
>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
CLASS="acronym"
>DNS</SPAN
> server for Unix machines, the Berkeley Internet
Name Domain (<SPAN
CLASS="acronym"
>BIND</SPAN
>) 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
CLASS="acronym"
>BIND</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 <SPAN
CLASS="acronym"
>BIND</SPAN
>
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 <SPAN
CLASS="acronym"
>BIND</SPAN
> for 2 years, from 1985
to 1987. Many other people also contributed to <SPAN
CLASS="acronym"
>BIND</SPAN
> development
during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell,
Mike Muuss, Jim Bloom and Mike Schwartz. <SPAN
CLASS="acronym"
>BIND</SPAN
> maintenance was subsequently
handled by Mike Karels and O. Kure.</P
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> 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
CLASS="acronym"
>BIND</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
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> Version 4.9.2 was sponsored by Vixie Enterprises. Paul
Vixie became <SPAN
CLASS="acronym"
>BIND</SPAN
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> 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 <SPAN
CLASS="acronym"
>BIND</SPAN
> version
8 in May 1997.</P
><P
><SPAN
CLASS="acronym"
>BIND</SPAN
> development work is made possible today by the sponsorship
of several corporations, and by the tireless work efforts of numerous
individuals.</P
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="historical_dns_information"
>A.2. Historical <SPAN
CLASS="acronym"
>DNS</SPAN
> Information</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="classes_of_resource_records"
>A.2.1. Classes of Resource Records</A
></H2
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="AEN3982"
>A.2.1.1. HS = hesiod</A
></H3
><P
>The [<SPAN
CLASS="optional"
>hesiod</SPAN
>] class is an information service
developed by MIT's Project Athena. It is used to share information
about various systems databases, such as users, groups, printers
and so on. The keyword <B
CLASS="command"
>hs</B
> is a synonym for
hesiod.</P
></DIV
><DIV
CLASS="sect3"
><H3
CLASS="sect3"
><A
NAME="AEN3987"
>A.2.1.2. CH = chaos</A
></H3
><P
>The <B
CLASS="command"
>chaos</B
> class is used to specify zone
data for the MIT-developed CHAOSnet, a LAN protocol created in the
mid-1970s.</P
></DIV
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="AEN3991"
>A.3. General <SPAN
CLASS="acronym"
>DNS</SPAN
> Reference Information</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN3994"
>A.3.1. IPv6 addresses (A6)</A
></H2
><P
>IPv6 addresses are 128-bit identifiers for interfaces and
sets of interfaces which were introduced in the <SPAN
CLASS="acronym"
>DNS</SPAN
> to facilitate
scalable Internet routing. There are three types of addresses: <I
CLASS="emphasis"
>Unicast</I
>,
an identifier for a single interface; <I
CLASS="emphasis"
>Anycast</I
>,
an identifier for a set of interfaces; and <I
CLASS="emphasis"
>Multicast</I
>,
an identifier for a set of interfaces. Here we describe the global
Unicast address scheme. For more information, see RFC 2374.</P
><P
>The aggregatable global Unicast address format is as follows:</P
><DIV
CLASS="informaltable"
><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><TR
><TD
WIDTH="46"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>3</P
></TD
><TD
WIDTH="48"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>13</P
></TD
><TD
WIDTH="50"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>8</P
></TD
><TD
WIDTH="70"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>24</P
></TD
><TD
WIDTH="129"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>16</P
></TD
><TD
WIDTH="243"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>64 bits</P
></TD
></TR
><TR
><TD
WIDTH="46"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>FP</P
></TD
><TD
WIDTH="48"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>TLA ID</P
></TD
><TD
WIDTH="50"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>RES</P
></TD
><TD
WIDTH="70"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>NLA ID</P
></TD
><TD
WIDTH="129"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>SLA ID</P
></TD
><TD
WIDTH="243"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Interface ID</P
></TD
></TR
><TR
><TD
COLSPAN="4"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><------ Public Topology
------></P
></TD
><TD
WIDTH="129"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="243"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
></TR
><TR
><TD
WIDTH="46"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="48"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="50"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="70"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="129"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><-Site Topology-></P
></TD
><TD
WIDTH="243"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
></TR
><TR
><TD
WIDTH="46"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="48"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="50"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="70"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="129"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
></P
></TD
><TD
WIDTH="243"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><------ Interface Identifier ------></P
></TD
></TR
></TABLE
><P
></P
></DIV
><P
>Where
<DIV
CLASS="informaltable"
><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>FP</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Format Prefix (001)</P
></TD
></TR
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>TLA ID</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Top-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>RES</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Reserved for future use</P
></TD
></TR
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>NLA ID</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Next-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>SLA ID</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Site-Level Aggregation Identifier</P
></TD
></TR
><TR
><TD
WIDTH="132"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>INTERFACE ID</P
></TD
><TD
WIDTH="24"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>=</P
></TD
><TD
WIDTH="336"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>Interface Identifier</P
></TD
></TR
></TABLE
><P
></P
></DIV
></P
><P
>The <I
CLASS="emphasis"
>Public Topology</I
> is provided by the
upstream provider or ISP, and (roughly) corresponds to the IPv4 <I
CLASS="emphasis"
>network</I
> section
of the address range. The <I
CLASS="emphasis"
>Site Topology</I
> is
where you can subnet this space, much the same as subnetting an
IPv4 /16 network into /24 subnets. The <I
CLASS="emphasis"
>Interface Identifier</I
> is
the address of an individual interface on a given network. (With
IPv6, addresses belong to interfaces rather than machines.)</P
><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
><P
>The internal structure of the Public Topology for an A6 global
unicast address consists of:</P
><DIV
CLASS="informaltable"
><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><TR
><TD
WIDTH="49"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>3</P
></TD
><TD
WIDTH="64"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>13</P
></TD
><TD
WIDTH="53"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>8</P
></TD
><TD
WIDTH="79"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>24</P
></TD
></TR
><TR
><TD
WIDTH="49"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>FP</P
></TD
><TD
WIDTH="64"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>TLA ID</P
></TD
><TD
WIDTH="53"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>RES</P
></TD
><TD
WIDTH="79"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>NLA ID</P
></TD
></TR
></TABLE
><P
></P
></DIV
><P
>A 3 bit FP (Format Prefix) of 001 indicates this is a global
Unicast address. FP lengths for other types of addresses may vary.</P
><P
>13 TLA (Top Level Aggregator) bits give the prefix of your
top-level IP backbone carrier.</P
><P
>8 Reserved bits</P
><P
>24 bits for Next Level Aggregators. This allows organizations
with a TLA to hand out portions of their IP space to client organizations,
so that the client can then split up the network further by filling
in more NLA bits, and hand out IPv6 prefixes to their clients, and
so forth.</P
><P
>There is no particular structure for the Site topology section.
Organizations can allocate these bits in any way they desire.</P
><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
><P
><B
CLASS="command"
>3ffe:8050:201:9:a00:20ff:fe81:2b32</B
></P
><P
>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
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="bibliography"
>A.4. Bibliography (and Suggested Reading)</A
></H1
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="rfcs"
>A.4.1. Request for Comments (RFCs)</A
></H2
><P
>Specification documents for the Internet protocol suite, including
the <SPAN
CLASS="acronym"
>DNS</SPAN
>, 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
<A
HREF="ftp://www.isi.edu/in-notes/"
TARGET="_top"
CLASS="replaceable"
><I
>xxx</I
></TT
>.txt</A
> (where <TT
CLASS="replaceable"
><I
>xxx</I
></TT
> is
the number of the RFC). RFCs are also available via the Web at <A
HREF="http://www.ietf.org/rfc/"
TARGET="_top"
>.</P
><H3
><A
NAME="AEN4170"
>Bibliography</A
></H3
><H1
CLASS="bibliodiv"
><A
NAME="AEN4171"
>Standards</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4173"
></A
><P
>[RFC974] C. Partridge, <I
>Mail Routing and the Domain System</I
>, January 1986.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4180"
></A
><P
>[RFC1034] P.V. Mockapetris, <I
>Domain Names — Concepts and Facilities</I
>, November 1987.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4187"
></A
><P
>[RFC1035] P. V. Mockapetris, <I
>Domain Names — Implementation and
Specification</I
>, November 1987.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="proposed_standards"
>Proposed Standards</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4196"
></A
><P
>[RFC2181] R., R. Bush Elz, <I
>Clarifications to the <SPAN
CLASS="acronym"
>DNS</SPAN
> Specification</I
>, July 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4204"
></A
><P
>[RFC2308] M. Andrews, <I
>Negative Caching of <SPAN
CLASS="acronym"
>DNS</SPAN
> Queries</I
>, March 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4212"
></A
><P
>[RFC1995] M. Ohta, <I
>Incremental Zone Transfer in <SPAN
CLASS="acronym"
>DNS</SPAN
></I
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4220"
></A
><P
>[RFC1996] P. Vixie, <I
>A Mechanism for Prompt Notification of Zone Changes</I
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4227"
></A
><P
>[RFC2136] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, <I
>Dynamic Updates in the Domain Name System</I
>, April 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4244"
></A
><P
>[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, 3rd, and B. Wellington, <I
>Secret Key Transaction Authentication for <SPAN
CLASS="acronym"
>DNS</SPAN
> (TSIG)</I
>, May 2000.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4263"
>Proposed Standards Still Under Development</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4268"
></A
><P
>[RFC1886] S. Thomson and C. Huitema, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> Extensions to support IP version 6</I
>, December 1995.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4280"
></A
><P
>[RFC2065] D. Eastlake, 3rd and C. Kaufman, <I
>Domain Name System Security Extensions</I
>, January 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4292"
></A
><P
>[RFC2137] D. Eastlake, 3rd, <I
>Secure Domain Name System Dynamic Update</I
>, April 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4300"
>Other Important RFCs About <SPAN
CLASS="acronym"
>DNS</SPAN
> Implementation</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4303"
></A
><P
>[RFC1535] E. Gavron, <I
>A Security Problem and Proposed Correction With Widely Deployed <SPAN
CLASS="acronym"
>DNS</SPAN
> Software.</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4311"
></A
><P
>[RFC1536] A. Kumar, J. Postel, C. Neuman, P. Danzig, and S. Miller, <I
>Common <SPAN
CLASS="acronym"
>DNS</SPAN
> Implementation Errors and Suggested Fixes</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4332"
></A
><P
>[RFC1982] R. Elz and R. Bush, <I
>Serial Number Arithmetic</I
>, August 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4343"
>Resource Record Types</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4345"
></A
><P
>[RFC1183] C.F. Everhart, L. A. Mamakos, R. Ullmann, and P. Mockapetris, <I
>New <SPAN
CLASS="acronym"
>DNS</SPAN
> RR Definitions</I
>, October 1990.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4363"
></A
><P
>[RFC1706] B. Manning and R. Colella, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> NSAP Resource Records</I
>, October 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4375"
></A
><P
>[RFC2168] R. Daniel and M. Mealling, <I
>Resolution of Uniform Resource Identifiers using
the Domain Name System</I
>, June 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4386"
></A
><P
>[RFC1876] C. Davis, P. Vixie, T., and I. Dickinson, <I
>A Means for Expressing Location Information in the Domain
Name System</I
>, January 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4403"
></A
><P
>[RFC2052] A. Gulbrandsen and P. Vixie, <I
>A <SPAN
CLASS="acronym"
>DNS</SPAN
> RR for Specifying the Location of
Services.</I
>, October 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4415"
></A
><P
>[RFC2163] A. Allocchio, <I
>Using the Internet <SPAN
CLASS="acronym"
>DNS</SPAN
> to Distribute MIXER
Conformant Global Address Mapping</I
>, January 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4423"
></A
><P
>[RFC2230] R. Atkinson, <I
>Key Exchange Delegation Record for the <SPAN
CLASS="acronym"
>DNS</SPAN
></I
>, October 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4431"
><SPAN
CLASS="acronym"
>DNS</SPAN
> and the Internet</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4434"
></A
><P
>[RFC1101] P. V. Mockapetris, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> Encoding of Network Names and Other Types</I
>, April 1989.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4442"
></A
><P
>[RFC1123] Braden, <I
>Requirements for Internet Hosts - Application and Support</I
>, October 1989.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4449"
></A
><P
>[RFC1591] J. Postel, <I
>Domain Name System Structure and Delegation</I
>, March 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4456"
></A
><P
>[RFC2317] H. Eidnes, G. de Groot, and P. Vixie, <I
>Classless IN-ADDR.ARPA Delegation</I
>, March 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4470"
><SPAN
CLASS="acronym"
>DNS</SPAN
> Operations</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4473"
></A
><P
>[RFC1537] P. Beertema, <I
>Common <SPAN
CLASS="acronym"
>DNS</SPAN
> Data File Configuration Errors</I
>, October 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4481"
></A
><P
>[RFC1912] D. Barr, <I
>Common <SPAN
CLASS="acronym"
>DNS</SPAN
> Operational and Configuration Errors</I
>, February 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4489"
></A
><P
>[RFC1912] D. Barr, <I
>Common <SPAN
CLASS="acronym"
>DNS</SPAN
> Operational and Configuration Errors</I
>, February 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4497"
></A
><P
>[RFC2010] B. Manning and P. Vixie, <I
>Operational Criteria for Root Name Servers.</I
>, October 1996.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4508"
></A
><P
>[RFC2219] M. Hamilton and R. Wright, <I
>Use of <SPAN
CLASS="acronym"
>DNS</SPAN
> Aliases for Network Services.</I
>, October 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4520"
>Other <SPAN
CLASS="acronym"
>DNS</SPAN
>-related RFCs</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4526"
></A
><P
>[RFC1464] R. Rosenbaum, <I
>Using the Domain Name System To Store Arbitrary String Attributes</I
>, May 1993.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4533"
></A
><P
>[RFC1713] A. Romao, <I
>Tools for <SPAN
CLASS="acronym"
>DNS</SPAN
> Debugging</I
>, November 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4541"
></A
><P
>[RFC1794] T. Brisco, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> Support for Load Balancing</I
>, April 1995.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4549"
></A
><P
>[RFC2240] O. Vaughan, <I
>A Legal Basis for Domain Name Allocation</I
>, November 1997.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4556"
></A
><P
>[RFC2345] J. Klensin, T. Wolf, and G. Oglesby, <I
>Domain Names and Company Name Retrieval</I
>, May 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><DIV
CLASS="biblioentry"
><A
NAME="AEN4570"
></A
><P
>[RFC2352] O. Vaughan, <I
>A Convention For Using Legal Names as Domain Names</I
>, May 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
><H1
CLASS="bibliodiv"
><A
NAME="AEN4577"
>Obsolete and Unimplemented Experimental RRs</A
></H1
><DIV
CLASS="biblioentry"
><A
NAME="AEN4579"
></A
><P
>[RFC1712] C. Farrell, M. Schulze, S. Pleitner, and D. Baldoni, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> Encoding of Geographical
Location</I
>, November 1994.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="internet_drafts"
>A.4.2. Internet Drafts</A
></H2
><P
>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.
</P
></DIV
><DIV
CLASS="sect2"
><H2
CLASS="sect2"
><A
NAME="AEN4600"
>A.4.3. Other Documents About <SPAN
CLASS="acronym"
>BIND</SPAN
></A
></H2
><P
></P
><H3
><A
NAME="AEN4604"
>Bibliography</A
></H3
><DIV
CLASS="biblioentry"
><A
NAME="AEN4605"
></A
><P
>Paul Albitz and Cricket Liu, <I
><SPAN
CLASS="acronym"
>DNS</SPAN
> and <SPAN
CLASS="acronym"
>BIND</SPAN
></I
>, 1998.</P
><DIV
CLASS="BIBLIOENTRYBLOCK"
STYLE="margin-left=0.5in"
></DIV
></DIV
></DIV
></DIV
><DIV
CLASS="sect1"
><H1
CLASS="sect1"
><A
NAME="statsfile"
>A.5. Format of statistics file</A
></H1
><P
>The statistics file generated by Bind9 is similar in form to that
generated by Bind8, but is not identical, due to differences in the counters
currently implemented in Bind9.</P
><P
>The statistics dump begins with the line <B
CLASS="command"
>+++ Statistics Dump
+++ (973798949)</B
>, where the number in parentheses is a standard
Unix-style timestamp, measured as seconds since January 1, 1970. Following
that line are a series of lines containing a counter type, value of the
listed are global counters for the entire server and the lines with view and
zones specified are for the given view and zone. The statistics dump ends
with the line <B
CLASS="command"
>--- Statistics Dump --- (973798949)</B
>, where the
number is identical to the number in the beginning line.</P
><P
>The following counters are defined:</P
><DIV
CLASS="informaltable"
><P
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>success</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number of
successful queries made to the server or zone. A successful query
is defined as query which returns a NOERROR result other than
delegation replies.</P
></TD
></TR
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>delegation</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number
of queries which return delegations instead a final answer.</P
></TD
></TR
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>nxrrset</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number
of queries made which return a result code of NXRRSET.</P
></TD
></TR
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>nxdoimain</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number
of queries made which return a result code of NXDOMAIN.</P
></TD
></TR
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>recursion</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number
of queries made which resulted in recursion in order to find the final
answer.</P
></TD
></TR
><TR
><TD
WIDTH="110"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
><B
CLASS="command"
>failure</B
></P
></TD
><TD
WIDTH="322"
ALIGN="LEFT"
VALIGN="MIDDLE"
><P
>This counter is used to track the number
of queries resulted in a SERVFAIL reply.</P
></TD
></TR
></TABLE
><P
></P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="Bv9ARM.ch08.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="Bv9ARM.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
> </TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Troubleshooting</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
> </TD
></TR
></TABLE
></DIV
></BODY
></HTML
>