</info>
<chapter xml:id="Bv9ARM.ch01"><info><title>Introduction</title></info>
-
+
<para>
The Internet Domain Name System (<acronym>DNS</acronym>)
consists of the syntax
hierarchical databases.
</para>
- <section><info><title>Scope of Document</title></info>
-
+ <section xml:id="doc_scope"><info><title>Scope of Document</title></info>
<para>
The Berkeley Internet Name Domain
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="pkgversion.xml"/>
</section>
- <section><info><title>Organization of This Document</title></info>
-
+ <section xml:id="organization"><info><title>Organization of This Document</title></info>
+
<para>
In this document, <emphasis>Chapter 1</emphasis> introduces
the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Chapter 2</emphasis>
System.
</para>
</section>
- <section><info><title>Conventions Used in This Document</title></info>
-
+ <section xml:id="conventions"><info><title>Conventions Used in This Document</title></info>
<para>
In this document, we use the following general typographic
</informaltable>
</para>
</section>
- <section><info><title>The Domain Name System (<acronym>DNS</acronym>)</title></info>
-
+ <section
xml:id="dns_overview"><info><title>The Domain Name System (<acronym>DNS</acronym>)</title></info>
+
<para>
The purpose of this document is to explain the installation
and upkeep of the <acronym>BIND</acronym> (Berkeley Internet
(<acronym>DNS</acronym>) as they relate to <acronym>BIND</acronym>.
</para>
- <section><info><title>DNS Fundamentals</title></info>
-
+ <section xml:id="dns_fundamentals"><info><title>DNS Fundamentals</title></info>
<para>
The Domain Name System (DNS) is a hierarchical, distributed
from ISC as a separate download.
</para>
- </section><section><info><title>Domains and Domain Names</title></info>
-
+ </section>
+ <section xml:id="domain_names"><info><title>Domains and Domain Names</title></info>
<para>
The data stored in the DNS is identified by <emphasis>domain names</emphasis> that are organized as a tree according to
</para>
</section>
- <section><info><title>Zones</title></info>
-
+ <section xml:id="zones"><info><title>Zones</title></info>
+
<para>
To properly operate a name server, it is important to understand
the difference between a <emphasis>zone</emphasis>
</para>
</section>
- <section><info><title>Authoritative Name Servers</title></info>
-
+ <section xml:id="auth_servers"><info><title>Authoritative Name Servers</title></info>
<para>
Each zone is served by at least
<command>dig</command> (<xref linkend="diagnostic_tools"/>).
</para>
- <section><info><title>The Primary Master</title></info>
-
+ <section xml:id="primary_master"><info><title>The Primary Master</title></info>
<para>
The authoritative server where the master copy of the zone
</para>
</section>
- <section><info><title>Slave Servers</title></info>
-
+ <section xml:id="slave_server"><info><title>Slave Servers</title></info>
+
<para>
The other authoritative servers, the <emphasis>slave</emphasis>
servers (also known as <emphasis>secondary</emphasis> servers)
</para>
</section>
- <section><info><title>Stealth Servers</title></info>
-
+ <section xml:id="stealth_server"><info><title>Stealth Servers</title></info>
<para>
Usually all of the zone's authoritative servers are listed in
</section>
</section>
- <section><info><title>Caching Name Servers</title></info>
-
-
+ <section xml:id="cache_servers"><info><title>Caching Name Servers</title></info>
<!--
- Terminology here is inconsistent. Probably ought to
Time To Live (TTL) field associated with each resource record.
</para>
- <section><info><title>Forwarding</title></info>
-
+ <section xml:id="forwarder"><info><title>Forwarding</title></info>
<para>
Even a caching name server does not necessarily perform
</section>
- <section><info><title>Name Servers in Multiple Roles</title></info>
-
+ <section xml:id="multi_role"><info><title>Name Servers in Multiple Roles</title></info>
<para>
The <acronym>BIND</acronym> name server can
</chapter>
<chapter xml:id="Bv9ARM.ch02"><info><title><acronym>BIND</acronym> Resource Requirements</title></info>
-
-
- <section><info><title>Hardware requirements</title></info>
-
+ <section xml:id="hw_req"><info><title>Hardware requirements</title></info>
<para>
<acronym>DNS</acronym> hardware requirements have
traditionally been quite modest.
multiprocessor systems for installations that need it.
</para>
</section>
- <section><info><title>CPU Requirements</title></info>
-
+ <section xml:id="cpu_req"><info><title>CPU Requirements</title></info>
<para>
CPU requirements for <acronym>BIND</acronym> 9 range from
i486-class machines
signed zones, serving many thousands of queries per second.
</para>
</section>
-
- <section><info><title>Memory Requirements</title></info>
-
+ <section xml:id="mem_req"><info><title>Memory Requirements</title></info>
<para>
The memory of the server has to be large enough to fit the
cache and zones loaded off disk. The <command>max-cache-size</command>
-->
</section>
- <section><info><title>Name Server Intensive Environment Issues</title></info>
-
+ <section xml:id="intensive_env"><info><title>Name Server Intensive Environment Issues</title></info>
+
<para>
For name server intensive environments, there are two alternative
configurations that may be used. The first is where clients and
</para>
</section>
- <section><info><title>Supported Operating Systems</title></info>
-
+ <section xml:id="supported_os"><info><title>Supported Operating Systems</title></info>
+
<para>
ISC <acronym>BIND</acronym> 9 compiles and runs on a large
number
</chapter>
<chapter xml:id="Bv9ARM.ch03"><info><title>Name Server Configuration</title></info>
-
+
<para>
In this chapter we provide some suggested configurations along
with guidelines for their use. We suggest reasonable values for
</para>
<section xml:id="sample_configuration"><info><title>Sample Configurations</title></info>
-
- <section><info><title>A Caching-only Name Server</title></info>
-
+
+ <section xml:id="cache_only_sample"><info><title>A Caching-only Name Server</title></info>
+
<para>
The following sample configuration is appropriate for a caching-only
name server for use by clients internal to a corporation. All
</section>
- <section><info><title>An Authoritative-only Name Server</title></info>
-
+ <section xml:id="auth_only_sample"><info><title>An Authoritative-only Name Server</title></info>
+
<para>
This sample configuration is for an authoritative-only server
that is the master server for "<filename>example.com</filename>"
</section>
</section>
- <section><info><title>Load Balancing</title></info>
-
+ <section xml:id="load_balancing"><info><title>Load Balancing</title></info>
+
<!--
- Add explanation of why load balancing is fragile at best
- and completely pointless in the general case.
</section>
- <section><info><title>Name Server Operations</title></info>
-
+ <section xml:id="ns_operations"><info><title>Name Server Operations</title></info>
- <section><info><title>Tools for Use With the Name Server Daemon</title></info>
-
+ <section xml:id="tools"><info><title>Tools for Use With the Name Server Daemon</title></info>
<para>
This section describes several indispensable diagnostic,
administrative and monitoring tools available to the system
daemon.
</para>
<section xml:id="diagnostic_tools"><info><title>Diagnostic Tools</title></info>
-
<para>
The <command>dig</command>, <command>host</command>, and
<command>nslookup</command> programs are all command
</section>
<section xml:id="admin_tools"><info><title>Administrative Tools</title></info>
-
<para>
Administrative tools play an integral part in the management
of a server.
</section>
</section>
- <section><info><title>Signals</title></info>
-
+ <section xml:id="signals"><info><title>Signals</title></info>
<para>
Certain UNIX signals cause the name server to take specific
actions, as described in the following table. These signals can
</chapter>
<chapter xml:id="Bv9ARM.ch04"><info><title>Advanced DNS Features</title></info>
-
<section xml:id="notify"><info><title>Notify</title></info>
-
-
<para>
<acronym>DNS</acronym> NOTIFY is a mechanism that allows master
servers to notify their slave servers of changes to a zone's data. In
</section>
<section xml:id="dynamic_update"><info><title>Dynamic Update</title></info>
-
<para>
Dynamic Update is a method for adding, replacing or deleting
</para>
<section xml:id="journal"><info><title>The journal file</title></info>
-
<para>
All changes made to a zone using dynamic update are stored
</section>
<section xml:id="incremental_zone_transfers"><info><title>Incremental Zone Transfers (IXFR)</title></info>
-
<para>
The incremental zone transfer (IXFR) protocol is a way for
</para>
</section>
- <section><info><title>Split DNS</title></info>
-
+ <section xml:id="split_dns"><info><title>Split DNS</title></info>
+
<para>
Setting up different views, or visibility, of the DNS space to
internal and external resolvers is usually referred to as a
on the Internet. Split DNS can also be used to allow mail from outside
back in to the internal network.
</para>
- <section><info><title>Example split DNS setup</title></info>
-
- <para>
- Let's say a company named <emphasis>Example, Inc.</emphasis>
- (<literal>example.com</literal>)
- has several corporate sites that have an internal network with
- reserved
- Internet Protocol (IP) space and an external demilitarized zone (DMZ),
- or "outside" section of a network, that is available to the public.
- </para>
- <para>
- <emphasis>Example, Inc.</emphasis> wants its internal clients
- to be able to resolve external hostnames and to exchange mail with
- people on the outside. The company also wants its internal resolvers
- to have access to certain internal-only zones that are not available
- at all outside of the internal network.
- </para>
- <para>
- In order to accomplish this, the company will set up two sets
- of name servers. One set will be on the inside network (in the
- reserved
- IP space) and the other set will be on bastion hosts, which are
- "proxy"
- hosts that can talk to both sides of its network, in the DMZ.
- </para>
- <para>
- The internal servers will be configured to forward all queries,
- except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
- and <filename>site2.example.com</filename>, to the servers
- in the
- DMZ. These internal servers will have complete sets of information
- for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>, <filename>site1.internal</filename>,
- and <filename>site2.internal</filename>.
- </para>
- <para>
- To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
- the internal name servers must be configured to disallow all queries
- to these domains from any external hosts, including the bastion
- hosts.
- </para>
- <para>
- The external servers, which are on the bastion hosts, will
- be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
- This could include things such as the host records for public servers
- (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
- and mail exchange (MX) records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
- </para>
- <para>
- In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
- should have special MX records that contain wildcard (`*') records
- pointing to the bastion hosts. This is needed because external mail
- servers do not have any other way of looking up how to deliver mail
- to those internal hosts. With the wildcard records, the mail will
- be delivered to the bastion host, which can then forward it on to
- internal hosts.
- </para>
- <para>
- Here's an example of a wildcard MX record:
- </para>
- <programlisting>* IN MX 10 external1.example.com.</programlisting>
- <para>
- Now that they accept mail on behalf of anything in the internal
- network, the bastion hosts will need to know how to deliver mail
- to internal hosts. In order for this to work properly, the resolvers
- on
- the bastion hosts will need to be configured to point to the internal
- name servers for DNS resolution.
- </para>
- <para>
- Queries for internal hostnames will be answered by the internal
- servers, and queries for external hostnames will be forwarded back
- out to the DNS servers on the bastion hosts.
- </para>
- <para>
- In order for all this to work properly, internal clients will
- need to be configured to query <emphasis>only</emphasis> the internal
- name servers for DNS queries. This could also be enforced via
- selective
- filtering on the network.
- </para>
- <para>
- If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
- internal clients will now be able to:
- </para>
- <itemizedlist>
- <listitem>
- <simpara>
- Look up any hostnames in the <literal>site1</literal>
- and
- <literal>site2.example.com</literal> zones.
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Look up any hostnames in the <literal>site1.internal</literal> and
- <literal>site2.internal</literal> domains.
- </simpara>
- </listitem>
- <listitem>
- <simpara>Look up any hostnames on the Internet.</simpara>
- </listitem>
- <listitem>
- <simpara>Exchange mail with both internal and external people.</simpara>
- </listitem>
- </itemizedlist>
- <para>
- Hosts on the Internet will be able to:
- </para>
- <itemizedlist>
- <listitem>
- <simpara>
- Look up any hostnames in the <literal>site1</literal>
- and
- <literal>site2.example.com</literal> zones.
- </simpara>
- </listitem>
- <listitem>
- <simpara>
- Exchange mail with anyone in the <literal>site1</literal> and
- <literal>site2.example.com</literal> zones.
- </simpara>
- </listitem>
- </itemizedlist>
+ <section xml:id="split_dns_sample"><info><title>Example split DNS setup</title></info>
+ <para>
+ Let's say a company named <emphasis>Example, Inc.</emphasis>
+ (<literal>example.com</literal>)
+ has several corporate sites that have an internal network with
+ reserved
+ Internet Protocol (IP) space and an external demilitarized zone (DMZ),
+ or "outside" section of a network, that is available to the public.
+ </para>
+ <para>
+ <emphasis>Example, Inc.</emphasis> wants its internal clients
+ to be able to resolve external hostnames and to exchange mail with
+ people on the outside. The company also wants its internal resolvers
+ to have access to certain internal-only zones that are not available
+ at all outside of the internal network.
+ </para>
+ <para>
+ In order to accomplish this, the company will set up two sets
+ of name servers. One set will be on the inside network (in the
+ reserved
+ IP space) and the other set will be on bastion hosts, which are
+ "proxy"
+ hosts that can talk to both sides of its network, in the DMZ.
+ </para>
+ <para>
+ The internal servers will be configured to forward all queries,
+ except queries for <filename>site1.internal</filename>, <filename>site2.internal</filename>, <filename>site1.example.com</filename>,
+ and <filename>site2.example.com</filename>, to the servers
+ in the
+ DMZ. These internal servers will have complete sets of information
+ for <filename>site1.example.com</filename>, <filename>site2.example.com</filename>, <filename>site1.internal</filename>,
+ and <filename>site2.internal</filename>.
+ </para>
+ <para>
+ To protect the <filename>site1.internal</filename> and <filename>site2.internal</filename> domains,
+ the internal name servers must be configured to disallow all queries
+ to these domains from any external hosts, including the bastion
+ hosts.
+ </para>
+ <para>
+ The external servers, which are on the bastion hosts, will
+ be configured to serve the "public" version of the <filename>site1</filename> and <filename>site2.example.com</filename> zones.
+ This could include things such as the host records for public servers
+ (<filename>www.example.com</filename> and <filename>ftp.example.com</filename>),
+ and mail exchange (MX) records (<filename>a.mx.example.com</filename> and <filename>b.mx.example.com</filename>).
+ </para>
+ <para>
+ In addition, the public <filename>site1</filename> and <filename>site2.example.com</filename> zones
+ should have special MX records that contain wildcard (`*') records
+ pointing to the bastion hosts. This is needed because external mail
+ servers do not have any other way of looking up how to deliver mail
+ to those internal hosts. With the wildcard records, the mail will
+ be delivered to the bastion host, which can then forward it on to
+ internal hosts.
+ </para>
+ <para>
+ Here's an example of a wildcard MX record:
+ </para>
+ <programlisting>* IN MX 10 external1.example.com.</programlisting>
+ <para>
+ Now that they accept mail on behalf of anything in the internal
+ network, the bastion hosts will need to know how to deliver mail
+ to internal hosts. In order for this to work properly, the resolvers
+ on
+ the bastion hosts will need to be configured to point to the internal
+ name servers for DNS resolution.
+ </para>
+ <para>
+ Queries for internal hostnames will be answered by the internal
+ servers, and queries for external hostnames will be forwarded back
+ out to the DNS servers on the bastion hosts.
+ </para>
+ <para>
+ In order for all this to work properly, internal clients will
+ need to be configured to query <emphasis>only</emphasis> the internal
+ name servers for DNS queries. This could also be enforced via
+ selective
+ filtering on the network.
+ </para>
+ <para>
+ If everything has been set properly, <emphasis>Example, Inc.</emphasis>'s
+ internal clients will now be able to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <simpara>
+ Look up any hostnames in the <literal>site1</literal>
+ and
+ <literal>site2.example.com</literal> zones.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Look up any hostnames in the <literal>site1.internal</literal> and
+ <literal>site2.internal</literal> domains.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>Look up any hostnames on the Internet.</simpara>
+ </listitem>
+ <listitem>
+ <simpara>Exchange mail with both internal and external people.</simpara>
+ </listitem>
+ </itemizedlist>
+ <para>
+ Hosts on the Internet will be able to:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <simpara>
+ Look up any hostnames in the <literal>site1</literal>
+ and
+ <literal>site2.example.com</literal> zones.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Exchange mail with anyone in the <literal>site1</literal> and
+ <literal>site2.example.com</literal> zones.
+ </simpara>
+ </listitem>
+ </itemizedlist>
- <para>
- Here is an example configuration for the setup we just
- described above. Note that this is only configuration information;
- for information on how to configure your zone files, see <xref linkend="sample_configuration"/>.
- </para>
+ Here is an example configuration for the setup we just
+ described above. Note that this is only configuration information;
+ for information on how to configure your zone files, see <xref linkend="sample_configuration"/>.
+ </para>
- <para>
- Internal DNS server config:
- </para>
+ Internal DNS server config:
+ </para>
<programlisting>
};
</programlisting>
- <para>
- External (bastion host) DNS server config:
- </para>
+ External (bastion host) DNS server config:
+ </para>
<programlisting>
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
};
</programlisting>
- <para>
- In the <filename>resolv.conf</filename> (or equivalent) on
- the bastion host(s):
- </para>
+ In the <filename>resolv.conf</filename> (or equivalent) on
+ the bastion host(s):
+ </para>
<programlisting>
search ...
nameserver 172.16.72.4
</programlisting>
- </section>
+ </section>
</section>
<section xml:id="tsig"><info><title>TSIG</title></info>
-
+
<para>
This is a short guide to setting up Transaction SIGnatures
(TSIG) based transaction security in <acronym>BIND</acronym>. It describes changes
</para>
<section><info><title>Generate Shared Keys for Each Pair of Hosts</title></info>
-
+
<para>
A shared secret is generated to be shared between <emphasis>host1</emphasis> and <emphasis>host2</emphasis>.
An arbitrary key name is chosen: "host1-host2.". The key name must
be the same on both hosts.
</para>
<section><info><title>Automatic Generation</title></info>
-
+
<para>
The following command will generate a 128-bit (16 byte) HMAC-SHA256
key as described above. Longer keys are better, but shorter keys
</para>
</section>
<section><info><title>Manual Generation</title></info>
-
+
<para>
The shared secret is simply a random sequence of bits, encoded
in base-64. Most ASCII strings are valid base-64 strings (assuming
</section>
</section>
<section><info><title>Copying the Shared Secret to Both Machines</title></info>
-
+
<para>
This is beyond the scope of DNS. A secure transport mechanism
should be used. This could be secure FTP, ssh, telephone, etc.
</para>
</section>
<section><info><title>Informing the Servers of the Key's Existence</title></info>
-
+
<para>
Imagine <emphasis>host1</emphasis> and <emphasis>host 2</emphasis>
are
</section>
<section><info><title>Instructing the Server to Use the Key</title></info>
-
+
<para>
Since keys are shared between two hosts only, the server must
be told when keys are to be used. The following is added to the <filename>named.conf</filename> file
</para>
</section>
<section><info><title>TSIG Key Based Access Control</title></info>
-
+
<para>
<acronym>BIND</acronym> allows IP addresses and ranges
to be specified in ACL
</section>
<section><info><title>Errors</title></info>
-
<para>
The processing of TSIG signed messages can result in
</section>
</section>
- <section><info><title>TKEY</title></info>
-
+ <section xml:id="tkey"><info><title>TKEY</title></info>
<para><command>TKEY</command>
is a mechanism for automatically generating a shared secret
</para>
</section>
- <section><info><title>SIG(0)</title></info>
-
+ <section xml:id="sig0"><info><title>SIG(0)</title></info>
<para>
<acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0)
</section>
<section xml:id="DNSSEC"><info><title>DNSSEC</title></info>
-
<para>
Cryptographic authentication of DNS information is possible
zone key of another zone above this one in the DNS tree.
</para>
- <section><info><title>Generating Keys</title></info>
-
+ <section xml:id="dnssec_keys"><info><title>Generating Keys</title></info>
<para>
The <command>dnssec-keygen</command> program is used to
</para>
</section>
- <section><info><title>Signing the Zone</title></info>
-
+ <section xml:id="dnssec_signing"><info><title>Signing the Zone</title></info>
<para>
The <command>dnssec-signzone</command> program is used
</section>
- <section><info><title>Configuring Servers</title></info>
-
+ <section xml:id="dnssec_config"><info><title>Configuring Servers</title></info>
<para>
To enable <command>named</command> to respond appropriately
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="dyndb.xml"/>
- <section><info><title>IPv6 Support in <acronym>BIND</acronym> 9</title></info>
+ <section
xml:id="ipv6"><info><title>IPv6 Support in <acronym>BIND</acronym> 9</title></info>
<para>
<acronym>BIND</acronym> 9 fully supports all currently
defined forms of IPv6 name to address and address to name
</para>
<section><info><title>Address Lookups Using AAAA Records</title></info>
-
<para>
The IPv6 AAAA record is a parallel to the IPv4 A record,
</para>
</section>
<section><info><title>Address to Name Lookups Using Nibble Format</title></info>
-
<para>
When looking up an address in nibble format, the address
</chapter>
<chapter xml:id="Bv9ARM.ch05"><info><title>The <acronym>BIND</acronym> 9 Lightweight Resolver</title></info>
-
- <section><info><title>The Lightweight Resolver Library</title></info>
-
+
+ <section xml:id="lightweight_resolver"><info><title>The Lightweight Resolver Library</title></info>
+
<para>
Traditionally applications have been linked with a stub resolver
library that sends recursive DNS queries to a local caching name
</para>
</section>
<section xml:id="lwresd"><info><title>Running a Resolver Daemon</title></info>
-
<para>
To use the lightweight resolver interface, the system must
</chapter>
<chapter xml:id="Bv9ARM.ch06"><info><title><acronym>BIND</acronym> 9 Configuration Reference</title></info>
-
<para>
<acronym>BIND</acronym> 9 configuration is broadly similar
<filename>contrib/named-bootconf/named-bootconf.sh</filename>.
</para>
<section xml:id="configuration_file_elements"><info><title>Configuration File Elements</title></info>
-
+
<para>
Following is a list of elements used throughout the <acronym>BIND</acronym> configuration
file documentation:
</tgroup>
</informaltable>
<section xml:id="address_match_lists"><info><title>Address Match Lists</title></info>
-
+
<section><info><title>Syntax</title></info>
-
<programlisting><varname>address_match_list</varname> = address_match_list_element ;
<optional> address_match_list_element; ... </optional>
</section>
<section><info><title>Definition and Usage</title></info>
-
+
<para>
Address match lists are primarily used to determine access
control for various server operations. They are also used in
</section>
</section>
- <section><info><title>Comment Syntax</title></info>
-
+ <section xml:id="comment_syntax"><info><title>Comment Syntax</title></info>
<para>
The <acronym>BIND</acronym> 9 comment syntax allows for
</para>
<section><info><title>Syntax</title></info>
-
<para>
<programlisting>/* This is a <acronym>BIND</acronym> comment as in C */</programlisting>
</para>
</section>
<section><info><title>Definition and Usage</title></info>
-
+
<para>
Comments may appear anywhere that whitespace may appear in
a <acronym>BIND</acronym> configuration file.
</section>
<section xml:id="Configuration_File_Grammar"><info><title>Configuration File Grammar</title></info>
-
<para>
A <acronym>BIND</acronym> 9 configuration consists of
configuration.
</para>
- <section><info><title><command>acl</command> Statement Grammar</title></info>
-
+ <section xml:id="acl_grammar"><info><title><command>acl</command> Statement Grammar</title></info>
<programlisting><command>acl</command> acl-name {
address_match_list
</section>
<section xml:id="acl"><info><title><command>acl</command> Statement Definition and
Usage</title></info>
-
<para>
The <command>acl</command> statement assigns a symbolic
</tgroup>
</informaltable>
</section>
- <section><info><title><command>controls</command> Statement Grammar</title></info>
-
+ <section xml:id="controls_grammar"><info><title><command>controls</command> Statement Grammar</title></info>
<programlisting><command>controls</command> {
[ inet ( ip_addr | * ) [ port ip_port ]
<section xml:id="controls_statement_definition_and_usage"><info><title><command>controls</command> Statement Definition and
Usage</title></info>
-
<para>
The <command>controls</command> statement declares control
</para>
</section>
- <section><info><title><command>include</command> Statement Grammar</title></info>
-
+ <section xml:id="include_grammar"><info><title><command>include</command> Statement Grammar</title></info>
+
<programlisting><command>include</command> <replaceable>filename</replaceable>;</programlisting>
</section>
- <section><info><title><command>include</command> Statement Definition and
- Usage</title></info>
-
+ <section xml:id="include_statement"><info><title><command>include</command> Statement Definition and Usage</title></info>
<para>
The <command>include</command> statement inserts the
</para>
</section>
- <section><info><title><command>key</command> Statement Grammar</title></info>
-
+ <section xml:id="key_grammar"><info><title><command>key</command> Statement Grammar</title></info>
<programlisting><command>key</command> <replaceable>key_id</replaceable> {
algorithm <replaceable>algorithm_id</replaceable>;
</section>
- <section><info><title><command>key</command> Statement Definition and Usage</title></info>
-
+ <section xml:id="key_statement"><info><title><command>key</command> Statement Definition and Usage</title></info>
<para>
The <command>key</command> statement defines a shared
</para>
</section>
- <section><info><title><command>logging</command> Statement Grammar</title></info>
-
+ <section xml:id="logging_grammar"><info><title><command>logging</command> Statement Grammar</title></info>
<programlisting><command>logging</command> {
[ <command>channel</command> <replaceable>channel_name</replaceable> {
</section>
- <section><info><title><command>logging</command> Statement Definition and
- Usage</title></info>
-
+ <section xml:id="logging_statement"><info><title><command>logging</command> Statement Definition and Usage</title></info>
<para>
The <command>logging</command> statement configures a
was specified.
</para>
- <section><info><title>The <command>channel</command> Phrase</title></info>
-
+ <section xml:id="channel"><info><title>The <command>channel</command> Phrase</title></info>
<para>
All log output goes to one or more <emphasis>channels</emphasis>;
</section>
<section xml:id="the_category_phrase"><info><title>The <command>category</command> Phrase</title></info>
-
<para>
There are many categories, so you can send the logs you want
</para>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="logging-categories.xml"/>
</section>
- <section><info><title>The <command>query-errors</command> Category</title></info>
+ <section xml:id="query_errors"><info><title>The <command>query-errors</command> Category</title></info>
<para>
The <command>query-errors</command> category is
specifically intended for debugging purposes: To identify
</section>
</section>
- <section><info><title><command>lwres</command> Statement Grammar</title></info>
-
+ <section xml:id="lwres_grammar"><info><title><command>lwres</command> Statement Grammar</title></info>
<para>
This is the grammar of the <command>lwres</command>
</programlisting>
</section>
- <section><info><title><command>lwres</command> Statement Definition and Usage</title></info>
-
+ <section xml:id="lwres_statement"><info><title><command>lwres</command> Statement Definition and Usage</title></info>
<para>
The <command>lwres</command> statement configures the
<option>lwres-tasks</option> times <option>lwres-clients</option>.
</para>
</section>
- <section><info><title><command>masters</command> Statement Grammar</title></info>
-
+ <section xml:id="masters_grammar"><info><title><command>masters</command> Statement Grammar</title></info>
<programlisting>
<command>masters</command> <replaceable>name</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>dscp <replaceable>ip_dscp</replaceable></optional> { ( <replaceable>masters_list</replaceable> |
</section>
- <section><info><title><command>masters</command> Statement Definition and
+ <section xml:id="masters_statement"><info><title><command>masters</command> Statement Definition and
Usage</title></info>
-
+
<para><command>masters</command>
lists allow for a common set of masters to be easily used by
multiple stub and slave zones in their <command>masters</command>
</para>
</section>
- <section><info><title><command>options</command> Statement Grammar</title></info>
-
+ <section xml:id="options_grammar"><info><title><command>options</command> Statement Grammar</title></info>
<para>
This is the grammar of the <command>options</command>
<section xml:id="options"><info><title><command>options</command> Statement Definition and
Usage</title></info>
-
<para>
The <command>options</command> statement sets up global
</variablelist>
<section xml:id="boolean_options"><info><title>Boolean Options</title></info>
-
<variablelist>
</section>
- <section><info><title>Forwarding</title></info>
-
+ <section xml:id="forwarding"><info><title>Forwarding</title></info>
+
<para>
The forwarding facility can be used to create a large site-wide
cache on a few servers, reducing traffic over links to external
</para>
</section>
- <section><info><title>Dual-stack Servers</title></info>
-
+ <section xml:id="dual_stack"><info><title>Dual-stack Servers</title></info>
+
<para>
Dual-stack servers are used as servers of last resort to work
around
</section>
<section xml:id="access_control"><info><title>Access Control</title></info>
-
+
<para>
Access to the server can be restricted based on the IP address
</section>
- <section><info><title>Interfaces</title></info>
-
+ <section xml:id="interfaces"><info><title>Interfaces</title></info>
+
<para>
The interfaces and ports that the server will answer queries
from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
</section>
<section xml:id="query_address"><info><title>Query Address</title></info>
-
+
<para>
If the server doesn't know the answer to a question, it will
query other name servers. <command>query-source</command> specifies
</section>
<section xml:id="zone_transfers"><info><title>Zone Transfers</title></info>
-
+
<para>
<acronym>BIND</acronym> has mechanisms in place to
facilitate zone transfers
</section>
- <section><info><title>UDP Port Lists</title></info>
-
+ <section xml:id="port_lists"><info><title>UDP Port Lists</title></info>
+
<para>
<command>use-v4-udp-ports</command>,
<command>avoid-v4-udp-ports</command>,
</para>
</section>
- <section><info><title>Operating System Resource Limits</title></info>
-
+ <section xml:id="resource_limits"><info><title>Operating System Resource Limits</title></info>
<para>
The server's usage of many system resources can be limited.
</section>
<section xml:id="server_resource_limits"><info><title>Server Resource Limits</title></info>
-
<para>
The following options set limits on the server's
</section>
- <section><info><title>Periodic Task Intervals</title></info>
-
+ <section xml:id="intervals"><info><title>Periodic Task Intervals</title></info>
<variablelist>
</section>
<section xml:id="topology"><info><title>Topology</title></info>
-
<para>
All other things being equal, when the server chooses a name
<section xml:id="the_sortlist_statement"><info><title>The <command>sortlist</command> Statement</title></info>
-
-
<para>
The response to a DNS query may consist of multiple resource
records (RRs) forming a resource records set (RRset).
</section>
<section xml:id="rrset_ordering"><info><title xml:id="rrset_ordering_title">RRset Ordering</title></info>
-
+
<para>
When multiple records are returned in an answer it may be
useful to configure the order of the records placed into the
</section>
<section xml:id="tuning"><info><title>Tuning</title></info>
-
<variablelist>
</section>
<section xml:id="builtin"><info><title>Built-in server information zones</title></info>
-
<para>
The server provides some helpful diagnostic information
</section>
<section xml:id="empty"><info><title>Built-in Empty Zones</title></info>
-
+
<para>
The <command>named</command> server has some built-in
empty zones (SOA and NS records only).
</section>
<section xml:id="acache"><info><title>Additional Section Caching</title></info>
-
+
<para>
The additional section cache, also called <command>acache</command>,
</section>
- <section><info><title>Content Filtering</title></info>
-
+ <section xml:id="content_filtering"><info><title>Content Filtering</title></info>
+
<para>
<acronym>BIND</acronym> 9 provides the ability to filter
out DNS responses from external DNS servers containing
</para>
</section>
- <section><info><title>Response Policy Zone (RPZ) Rewriting</title></info>
-
+ <section xml:id="rpz"><info><title>Response Policy Zone (RPZ) Rewriting</title></info>
+
<para>
<acronym>BIND</acronym> 9 includes a limited
mechanism to modify DNS responses for requests
</para>
</section>
- <section><info><title>Response Rate Limiting</title></info>
-
+ <section xml:id="rrl"><info><title>Response Rate Limiting</title></info>
+
<para>
Excessive almost identical UDP <emphasis>responses</emphasis>
can be controlled by configuring a
</section>
<section xml:id="server_statement_grammar"><info><title><command>server</command> Statement Grammar</title></info>
-
<programlisting><command>server</command> <replaceable>ip_addr[/prefixlen]</replaceable> {
<optional> bogus <replaceable>yes_or_no</replaceable> ; </optional>
<section xml:id="server_statement_definition_and_usage"><info><title><command>server</command> Statement Definition and
Usage</title></info>
-
<para>
The <command>server</command> statement defines
</section>
<section xml:id="statschannels"><info><title><command>statistics-channels</command> Statement Grammar</title></info>
-
<programlisting><command>statistics-channels</command> {
[ inet ( ip_addr | * ) [ port ip_port ]
</programlisting>
</section>
- <section><info><title><command>statistics-channels</command> Statement Definition and
+ <section xml:id="statistics_channels"><info><title><command>statistics-channels</command> Statement Definition and
Usage</title></info>
-
<para>
The <command>statistics-channels</command> statement
</section>
<section xml:id="trusted-keys"><info><title><command>trusted-keys</command> Statement Grammar</title></info>
-
<programlisting><command>trusted-keys</command> {
<replaceable>string</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ;
</programlisting>
</section>
- <section><info><title><command>trusted-keys</command> Statement Definition
+ <section xml:id="trusted_keys"><info><title><command>trusted-keys</command> Statement Definition
and Usage</title></info>
-
+
<para>
The <command>trusted-keys</command> statement defines
DNSSEC security roots. DNSSEC is described in <xref linkend="DNSSEC"/>. A security root is defined when the
</para>
</section>
- <section><info><title><command>managed-keys</command> Statement Grammar</title></info>
-
+ <section xml:id="managed_keys"><info><title><command>managed-keys</command> Statement Grammar</title></info>
<programlisting><command>managed-keys</command> {
<replaceable>name</replaceable> initial-key <replaceable>flags</replaceable> <replaceable>protocol</replaceable> <replaceable>algorithm</replaceable> <replaceable>key-data</replaceable> ;
</section>
<section xml:id="managed-keys"><info><title><command>managed-keys</command> Statement Definition
and Usage</title></info>
-
+
<para>
The <command>managed-keys</command> statement, like
<command>trusted-keys</command>, defines DNSSEC
</section>
<section xml:id="view_statement_grammar"><info><title><command>view</command> Statement Grammar</title></info>
-
<programlisting><command>view</command> <replaceable>view_name</replaceable>
<optional><replaceable>class</replaceable></optional> {
</programlisting>
</section>
- <section><info><title><command>view</command> Statement Definition and Usage</title></info>
-
+ <section xml:id="view_statement"><info><title><command>view</command> Statement Definition and Usage</title></info>
<para>
The <command>view</command> statement is a powerful
</section>
<section xml:id="zone_statement_grammar"><info><title><command>zone</command>
Statement Grammar</title></info>
-
<programlisting><command>zone</command> <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
type master;
</programlisting>
</section>
- <section><info><title><command>zone</command> Statement Definition and Usage</title></info>
-
- <section><info><title>Zone Types</title></info>
+ <section xml:id="zone_statement"><info><title><command>zone</command> Statement Definition and Usage</title></info>
+
+ <section xml:id="zone_types"><info><title>Zone Types</title></info>
<para>
The <command>type</command> keyword is required
for the <command>zone</command> configuration unless
<varname>slave</varname>, <varname>static-stub</varname>,
and <varname>stub</varname>.
</para>
-
+
<informaltable colsep="0" rowsep="0">
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="3Level-table">
<!--colspec colname="1" colnum="1" colsep="0" colwidth="1.108in"/-->
</informaltable>
</section>
- <section><info><title>Class</title></info>
-
+ <section xml:id="class"><info><title>Class</title></info>
+
<para>
The zone's name may optionally be followed by a class. If
a class is not specified, class <literal>IN</literal> (for <varname>Internet</varname>),
</para>
</section>
- <section><info><title>Zone Options</title></info>
-
+ <section xml:id="zone_options"><info><title>Zone Options</title></info>
<variablelist>
</section>
<section xml:id="dynamic_update_policies"><info><title>Dynamic Update Policies</title></info>
-
+
<para><acronym>BIND</acronym> 9 supports two alternative
methods of granting clients the right to perform
dynamic updates to a zone, configured by the
</para>
</section>
- <section><info><title>Multiple views</title></info>
-
+ <section xml:id="multiple_views"><info><title>Multiple views</title></info>
+
<para>
When multiple views are in use, a zone may be
referenced by more than one of them. Often, the views
</section>
</section>
- <section><info><title>Zone File</title></info>
-
+ <section xml:id="zone_file"><info><title>Zone File</title></info>
+
<section xml:id="types_of_resource_records_and_when_to_use_them"><info><title>Types of Resource Records and When to Use Them</title></info>
-
+
<para>
This section, largely borrowed from RFC 1034, describes the
concept of a Resource Record (RR) and explains when each is used.
and implemented in the DNS. These are also included.
</para>
<section><info><title>Resource Records</title></info>
-
<para>
A domain name identifies a node. Each node has a set of
used as "pointers" to other data in the DNS.
</para>
</section>
- <section><info><title>Textual expression of RRs</title></info>
-
+ <section xml:id="rr_text"><info><title>Textual expression of RRs</title></info>
+
<para>
RRs are represented in binary form in the packets of the DNS
protocol, and are usually represented in highly encoded form
</section>
</section>
- <section><info><title>Discussion of MX Records</title></info>
-
+ <section xml:id="mx_records"><info><title>Discussion of MX Records</title></info>
<para>
As described above, domain servers store information as a
</para>
</section>
<section xml:id="Setting_TTLs"><info><title>Setting TTLs</title></info>
-
+
<para>
The time-to-live of the RR field is a 32-bit integer represented
in units of seconds, and is primarily used by resolvers when they
can be explicitly specified, for example, <literal>1h30m</literal>.
</para>
</section>
- <section><info><title>Inverse Mapping in IPv4</title></info>
-
+ <section xml:id="ipv4_reverse"><info><title>Inverse Mapping in IPv4</title></info>
+
<para>
Reverse name resolution (that is, translation from IP address
to name) is achieved by means of the <emphasis>in-addr.arpa</emphasis> domain
</para>
</note>
</section>
- <section><info><title>Other Zone File Directives</title></info>
-
+ <section xml:id="zone_directives"><info><title>Other Zone File Directives</title></info>
+
<para>
The Master File Format was initially defined in RFC 1035 and
has subsequently been extended. While the Master File Format
Master File Directives include <command>$ORIGIN</command>, <command>$INCLUDE</command>,
and <command>$TTL.</command>
</para>
- <section><info><title>The <command>@</command> (at-sign)</title></info>
-
+ <section xml:id="atsign"><info><title>The <command>@</command> (at-sign)</title></info>
+
<para>
When used in the label (or name) field, the asperand or
at-sign (@) symbol represents the current origin.
trailing dot).
</para>
</section>
- <section><info><title>The <command>$ORIGIN</command> Directive</title></info>
-
+ <section xml:id="origin_directive"><info><title>The <command>$ORIGIN</command> Directive</title></info>
+
<para>
Syntax: <command>$ORIGIN</command>
<replaceable>domain-name</replaceable>
</programlisting>
</section>
- <section><info><title>The <command>$INCLUDE</command> Directive</title></info>
-
+ <section xml:id="include_directive"><info><title>The <command>$INCLUDE</command> Directive</title></info>
+
<para>
Syntax: <command>$INCLUDE</command>
<replaceable>filename</replaceable>
</para>
</note>
</section>
- <section><info><title>The <command>$TTL</command> Directive</title></info>
-
+ <section xml:id="ttl_directive"><info><title>The <command>$TTL</command> Directive</title></info>
+
<para>
Syntax: <command>$TTL</command>
<replaceable>default-ttl</replaceable>
</para>
</section>
</section>
- <section><info><title><acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive</title></info>
-
+ <section
xml:id="generate_directive"><info><title><acronym>BIND</acronym> Master File Extension: the <command>$GENERATE</command> Directive</title></info>
+
<para>
Syntax: <command>$GENERATE</command>
<replaceable>range</replaceable>
</section>
<section xml:id="zonefile_format"><info><title>Additional File Formats</title></info>
-
+
<para>
In addition to the standard textual format, BIND 9
supports the ability to read or dump to zone files in
</section>
<section xml:id="statistics"><info><title>BIND9 Statistics</title></info>
-
+
<para>
<acronym>BIND</acronym> 9 maintains lots of statistics
information and provides several interfaces for users to
</para>
<section xml:id="statsfile"><info><title>The Statistics File</title></info>
-
+
<para>
The text format statistics dump begins with a line, like:
</para>
</section>
<section xml:id="statistics_counters"><info><title>Statistics Counters</title></info>
-
+
<para>
The following tables summarize statistics counters that
<acronym>BIND</acronym> 9 provides.
<acronym>BIND</acronym> 8 statistics, if applicable.
</para>
- <section><info><title>Name Server Statistics Counters</title></info>
-
+ <section xml:id="stats_counters"><info><title>Name Server Statistics Counters</title></info>
<informaltable colsep="0" rowsep="0">
<tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
</informaltable>
</section>
- <section><info><title>Zone Maintenance Statistics Counters</title></info>
-
+ <section xml:id="zone_stats"><info><title>Zone Maintenance Statistics Counters</title></info>
<informaltable colsep="0" rowsep="0">
<tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
</informaltable>
</section>
- <section><info><title>Resolver Statistics Counters</title></info>
-
+ <section xml:id="resolver_stats"><info><title>Resolver Statistics Counters</title></info>
<informaltable colsep="0" rowsep="0">
<tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
</section>
- <section><info><title>Socket I/O Statistics Counters</title></info>
-
+ <section xml:id="socket_stats"><info><title>Socket I/O Statistics Counters</title></info>
<para>
Socket I/O statistics counters are defined per socket
</tgroup>
</informaltable>
</section>
- <section><info><title>Compatibility with <emphasis>BIND</emphasis> 8 Counters</title></info>
-
+
+ <section xml:id="bind8_compatibility"><info><title>Compatibility with <emphasis>BIND</emphasis> 8 Counters</title></info>
+
<para>
Most statistics counters that were available
in <command>BIND</command> 8 are also supported in
</chapter>
<chapter xml:id="Bv9ARM.ch07"><info><title><acronym>BIND</acronym> 9 Security Considerations</title></info>
-
+
<section xml:id="Access_Control_Lists"><info><title>Access Control Lists</title></info>
-
+
<para>
Access Control Lists (ACLs) are address match lists that
you can set up and nickname for future use in
</para>
</section>
- <section><info><title><command>Chroot</command> and <command>Setuid</command></title></info>
-
+ <section xml:id="chroot_and_setuid"><info><title><command>Chroot</command> and <command>Setuid</command></title></info>
+
<para>
On UNIX servers, it is possible to run <acronym>BIND</acronym>
in a <emphasis>chrooted</emphasis> environment (using
<userinput>/usr/local/sbin/named -u 202 -t /var/named</userinput>
</para>
- <section><info><title>The <command>chroot</command> Environment</title></info>
-
+ <section xml:id="chroot"><info><title>The <command>chroot</command> Environment</title></info>
<para>
In order for a <command>chroot</command> environment
</para>
</section>
- <section><info><title>Using the <command>setuid</command> Function</title></info>
-
+ <section xml:id="setuid"><info><title>Using the <command>setuid</command> Function</title></info>
<para>
Prior to running the <command>named</command> daemon,
</section>
<section xml:id="dynamic_update_security"><info><title>Dynamic Update Security</title></info>
-
<para>
Access to the dynamic
</chapter>
<chapter xml:id="Bv9ARM.ch08"><info><title>Troubleshooting</title></info>
-
- <section><info><title>Common Problems</title></info>
-
+
+ <section xml:id="common_problems"><info><title>Common Problems</title></info>
+
<section><info><title>It's not working; how can I figure out what's wrong?</title></info>
-
<para>
The best solution to solving installation and
</section>
</section>
<section><info><title>Incrementing and Changing the Serial Number</title></info>
-
<para>
Zone serial numbers are just numbers — they aren't
</para>
</section>
- <section><info><title>Where Can I Get Help?</title></info>
-
+ <section xml:id="more_help"><info><title>Where Can I Get Help?</title></info>
<para>
The Internet Systems Consortium
</chapter>
<appendix xml:id="Bv9ARM.ch09"><info><title>Release Notes</title></info>
-
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="notes.xml"/>
</appendix>
<appendix xml:id="Bv9ARM.ch10"><info><title>A Brief History of the <acronym>DNS</acronym> and <acronym>BIND</acronym></title></info>
-
- <section xml:id="dns_history"><info><title>DNS</title></info>
- <para>
- 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 a 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 <acronym>DNS</acronym> implementations are
- built.
- </para>
-
- <para>
- 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 <acronym>DNS</acronym> server for
- Unix machines, the Berkeley Internet
- Name Domain (<acronym>BIND</acronym>) 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).
- </para>
- </section>
+ <para xml:id="historical_dns_information">
+ 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 a 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 <acronym>DNS</acronym> implementations are
+ built.
+ </para>
- <section xml:id="bind_history"><info><title>BIND</title></info>
- <para>
- Versions of <acronym>BIND</acronym> 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 <acronym>BIND</acronym>
- 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 <acronym>BIND</acronym> for 2 years, from 1985
- to 1987. Many other people also contributed to <acronym>BIND</acronym> development
- during that time: Doug Kingston, Craig Partridge, Smoot
- Carl-Mitchell,
- Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
- handled by Mike Karels and Øivind Kure.
- </para>
- <para>
- <acronym>BIND</acronym> versions 4.9 and 4.9.1 were
- released by Digital Equipment
- Corporation (now Compaq Computer Corporation). Paul Vixie, then
- a DEC employee, became <acronym>BIND</acronym>'s
- primary caretaker. He 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.
- </para>
- <para>
- In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
- Vixie Enterprises. Paul
- Vixie became <acronym>BIND</acronym>'s principal
- architect/programmer.
- </para>
- <para>
- <acronym>BIND</acronym> versions from 4.9.3 onward
- have been developed and maintained
- by the Internet Systems Consortium and its predecessor,
- the Internet Software Consortium, with support being provided
- by ISC's sponsors.
- </para>
- <para>
- As co-architects/programmers, Bob Halley and
- Paul Vixie released the first production-ready version of
- <acronym>BIND</acronym> version 8 in May 1997.
- </para>
- <para>
- BIND version 9 was released in September 2000 and is a
- major rewrite of nearly all aspects of the underlying
- BIND architecture.
- </para>
- <para>
- BIND versions 4 and 8 are officially deprecated.
- No additional development is done
- on BIND version 4 or BIND version 8.
- </para>
- <para>
- <acronym>BIND</acronym> development work is made
- possible today by the sponsorship
- of several corporations, and by the tireless work efforts of
- numerous individuals.
- </para>
- </section>
+ <para>
+ 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 <acronym>DNS</acronym> server for
+ Unix machines, the Berkeley Internet
+ Name Domain (<acronym>BIND</acronym>) 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).
+ </para>
+ <para>
+ Versions of <acronym>BIND</acronym> 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 <acronym>BIND</acronym>
+ 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 <acronym>BIND</acronym> for 2 years, from 1985
+ to 1987. Many other people also contributed to <acronym>BIND</acronym> development
+ during that time: Doug Kingston, Craig Partridge, Smoot
+ Carl-Mitchell,
+ Mike Muuss, Jim Bloom and Mike Schwartz. <acronym>BIND</acronym> maintenance was subsequently
+ handled by Mike Karels and Øivind Kure.
+ </para>
+ <para>
+ <acronym>BIND</acronym> versions 4.9 and 4.9.1 were
+ released by Digital Equipment
+ Corporation (now Compaq Computer Corporation). Paul Vixie, then
+ a DEC employee, became <acronym>BIND</acronym>'s
+ primary caretaker. He 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.
+ </para>
+ <para>
+ In 1994, <acronym>BIND</acronym> version 4.9.2 was sponsored by
+ Vixie Enterprises. Paul
+ Vixie became <acronym>BIND</acronym>'s principal
+ architect/programmer.
+ </para>
+ <para>
+ <acronym>BIND</acronym> versions from 4.9.3 onward
+ have been developed and maintained
+ by the Internet Systems Consortium and its predecessor,
+ the Internet Software Consortium, with support being provided
+ by ISC's sponsors.
+ </para>
+ <para>
+ As co-architects/programmers, Bob Halley and
+ Paul Vixie released the first production-ready version of
+ <acronym>BIND</acronym> version 8 in May 1997.
+ </para>
+ <para>
+ BIND version 9 was released in September 2000 and is a
+ major rewrite of nearly all aspects of the underlying
+ BIND architecture.
+ </para>
+ <para>
+ BIND versions 4 and 8 are officially deprecated.
+ No additional development is done
+ on BIND version 4 or BIND version 8.
+ </para>
+ <para>
+ <acronym>BIND</acronym> development work is made
+ possible today by the sponsorship
+ of several corporations, and by the tireless work efforts of
+ numerous individuals.
+ </para>
</appendix>
<appendix xml:id="Bv9ARM.ch11"><info><title>General <acronym>DNS</acronym> Reference Information</title></info>
-
+
<section xml:id="ipv6addresses"><info><title>IPv6 addresses (AAAA)</title></info>
-
+
<para>
IPv6 addresses are 128-bit identifiers for interfaces and
sets of interfaces which were introduced in the <acronym>DNS</acronym> to facilitate
</para>
</section>
<section xml:id="bibliography"><info><title>Bibliography (and Suggested Reading)</title></info>
-
+
<section xml:id="rfcs"><info><title>Request for Comments (RFCs)</title></info>
-
+
<para>
Specification documents for the Internet protocol suite, including
the <acronym>DNS</acronym>, are published as part of
<bibliography>
<bibliodiv><info><title>Standards</title></info>
<!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
-
+
<biblioentry>
<abbrev>RFC974</abbrev>
<author><personname><surname>Partridge</surname><firstname>C.</firstname></personname></author>
</bibliodiv>
<bibliodiv xml:id="proposed_standards" xreflabel="Proposed Standards"><info><title>Proposed Standards</title></info>
-
<!-- one of (BIBLIOENTRY BIBLIOMIXED) -->
<biblioentry>
<abbrev>RFC2181</abbrev>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title><acronym>DNS</acronym> Security Proposed Standards</title></info>
-
+
<biblioentry>
<abbrev>RFC3225</abbrev>
<authorgroup>
</bibliodiv>
<bibliodiv><info><title>Other Important RFCs About <acronym>DNS</acronym>
Implementation</title></info>
-
+
<biblioentry>
<abbrev>RFC1535</abbrev>
<author><personname><surname>Gavron</surname><firstname>E.</firstname></personname></author>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title>Resource Record Types</title></info>
-
+
<biblioentry>
<abbrev>RFC1183</abbrev>
<authorgroup>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title><acronym>DNS</acronym> and the Internet</title></info>
-
+
<biblioentry>
<abbrev>RFC1101</abbrev>
<author><personname><surname>Mockapetris</surname><firstname>P. V.</firstname></personname></author>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title><acronym>DNS</acronym> Operations</title></info>
-
+
<biblioentry>
<abbrev>RFC1033</abbrev>
<author><personname><surname>Lottor</surname><firstname>M.</firstname></personname></author>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title>Internationalized Domain Names</title></info>
-
+
<biblioentry>
<abbrev>RFC2825</abbrev>
<authorgroup>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title>Other <acronym>DNS</acronym>-related RFCs</title></info>
-
+
<note>
<para>
Note: the following list of RFCs, although
</biblioentry>
</bibliodiv>
<bibliodiv><info><title>Obsolete and Unimplemented Experimental RFC</title></info>
-
+
<biblioentry>
<abbrev>RFC1712</abbrev>
<authorgroup>
</biblioentry>
</bibliodiv>
<bibliodiv><info><title>Obsoleted DNS Security RFCs</title></info>
-
+
<note>
<para>
Most of these have been consolidated into RFC4033,
</bibliography>
</section>
<section xml:id="internet_drafts"><info><title>Internet Drafts</title></info>
-
+
<para>
Internet Drafts (IDs) are rough-draft working documents of
the Internet Engineering Task Force. They are, in essence, RFCs
after which they are deleted unless updated by their authors.
</para>
</section>
- <section><info><title>Other Documents About <acronym>BIND</acronym></title></info>
-
+ <section
xml:id="more_about_bind"><info><title>Other Documents About <acronym>BIND</acronym></title></info>
+
<para/>
<bibliography>
<biblioentry>
</appendix>
<appendix xml:id="Bv9ARM.ch12"><info><title>BIND 9 DNS Library Support</title></info>
-
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="libdns.xml"/>
</appendix>
<reference xml:id="Bv9ARM.ch13"><info><title>Manual pages</title></info>
-
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/dig.docbook"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/dig/host.docbook"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="../../bin/delv/delv.docbook"/>
projects / thirdparty / bind9.git / commitdiff
