Table of Contents
The Berkeley Internet Name Domain (BIND) implements a @@ -84,7 +84,7 @@
In this document, Chapter 1 introduces the basic DNS and BIND concepts. Chapter 2 @@ -113,7 +113,7 @@
In this document, we use the following general typographic conventions: @@ -240,7 +240,7 @@
The purpose of this document is to explain the installation and upkeep of the BIND (Berkeley Internet @@ -250,7 +250,7 @@
The Domain Name System (DNS) is a hierarchical, distributed database. It stores information for mapping Internet host names to @@ -272,7 +272,7 @@
The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries. Each node of the tree, @@ -318,7 +318,7 @@
To properly operate a name server, it is important to understand the difference between a zone @@ -371,7 +371,7 @@
Each zone is served by at least one authoritative name server, @@ -388,7 +388,7 @@
The authoritative server where the master copy of the zone data is maintained is called the @@ -408,7 +408,7 @@
The other authoritative servers, the slave servers (also known as secondary servers) @@ -424,7 +424,7 @@
Usually all of the zone's authoritative servers are listed in NS records in the parent zone. These NS records constitute @@ -459,7 +459,7 @@
The resolver libraries provided by most operating systems are stub resolvers, meaning that they are not @@ -486,7 +486,7 @@
Even a caching name server does not necessarily perform the complete recursive lookup itself. Instead, it can @@ -513,7 +513,7 @@
The BIND name server can simultaneously act as diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html index 60bd85321f..89b2fb0eb7 100644 --- a/doc/arm/Bv9ARM.ch02.html +++ b/doc/arm/Bv9ARM.ch02.html @@ -44,16 +44,16 @@
Table of Contents
DNS hardware requirements have traditionally been quite modest. @@ -72,7 +72,7 @@
CPU requirements for BIND 9 range from i486-class machines @@ -83,7 +83,7 @@
The memory of the server has to be large enough to fit the cache and zones loaded off disk. The max-cache-size @@ -106,7 +106,7 @@
For name server intensive environments, there are two alternative configurations that may be used. The first is where clients and @@ -123,7 +123,7 @@
ISC BIND 9 compiles and runs on a large number diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html index 03d28207d5..2a4c24b314 100644 --- a/doc/arm/Bv9ARM.ch03.html +++ b/doc/arm/Bv9ARM.ch03.html @@ -46,14 +46,14 @@
The following sample configuration is appropriate for a caching-only name server for use by clients internal to a corporation. All @@ -97,7 +97,7 @@ zone "0.0.127.in-addr.arpa" {
This sample configuration is for an authoritative-only server
that is the master server for "example.com"
@@ -145,7 +145,7 @@ zone "eng.example.com" {
A primitive form of load balancing can be achieved in the DNS by using multiple records @@ -288,10 +288,10 @@ zone "eng.example.com" {
This section describes several indispensable diagnostic, administrative and monitoring tools available to the system @@ -598,7 +598,7 @@ controls {
Certain UNIX signals cause the name server to take specific actions, as described in the following table. These signals can diff --git a/doc/arm/Bv9ARM.ch04.html b/doc/arm/Bv9ARM.ch04.html index 3d1de562a4..e8b4cc2ab2 100644 --- a/doc/arm/Bv9ARM.ch04.html +++ b/doc/arm/Bv9ARM.ch04.html @@ -48,8 +48,8 @@
Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a @@ -294,124 +294,124 @@
- Let's say a company named Example, Inc.
- (example.com)
- 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.
-
example.com)
+ 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.
+
- Example, Inc. 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. -
+ Example, Inc. 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. +- 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. -
+ 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. +
- The internal servers will be configured to forward all queries,
- except queries for site1.internal, site2.internal, site1.example.com,
- and site2.example.com, to the servers
- in the
- DMZ. These internal servers will have complete sets of information
- for site1.example.com, site2.example.com, site1.internal,
- and site2.internal.
-
site1.internal, site2.internal, site1.example.com,
+ and site2.example.com, to the servers
+ in the
+ DMZ. These internal servers will have complete sets of information
+ for site1.example.com, site2.example.com, site1.internal,
+ and site2.internal.
+
- To protect the site1.internal and site2.internal domains,
- the internal name servers must be configured to disallow all queries
- to these domains from any external hosts, including the bastion
- hosts.
-
site1.internal and site2.internal domains,
+ the internal name servers must be configured to disallow all queries
+ to these domains from any external hosts, including the bastion
+ hosts.
+
- The external servers, which are on the bastion hosts, will
- be configured to serve the "public" version of the site1 and site2.example.com zones.
- This could include things such as the host records for public servers
- (www.example.com and ftp.example.com),
- and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).
-
site1 and site2.example.com zones.
+ This could include things such as the host records for public servers
+ (www.example.com and ftp.example.com),
+ and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).
+
- In addition, the public site1 and site2.example.com 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.
-
site1 and site2.example.com 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.
+
- Here's an example of a wildcard MX record: -
+ Here's an example of a wildcard MX record: +* IN MX 10 external1.example.com.
- 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. -
+ 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. +- 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. -
+ 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. +- In order for all this to work properly, internal clients will - need to be configured to query only the internal - name servers for DNS queries. This could also be enforced via - selective - filtering on the network. -
+ In order for all this to work properly, internal clients will + need to be configured to query only the internal + name servers for DNS queries. This could also be enforced via + selective + filtering on the network. +- If everything has been set properly, Example, Inc.'s - internal clients will now be able to: -
+ If everything has been set properly, Example, Inc.'s + internal clients will now be able to: +site1
- and
- site2.example.com zones.
- site1
+ and
+ site2.example.com zones.
+
site1.internal and
- site2.internal domains.
- site1.internal and
+ site2.internal domains.
+
- Hosts on the Internet will be able to: -
+ Hosts on the Internet will be able to: +site1
- and
- site2.example.com zones.
- site1
+ and
+ site2.example.com zones.
+
site1 and
- site2.example.com zones.
- site1 and
+ site2.example.com zones.
+
- 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 the section called “Sample Configurations”. -
+ 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 the section called “Sample Configurations”. +- Internal DNS server config: -
+ Internal DNS server config: +
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
@@ -474,8 +474,8 @@ zone "site2.internal" {
};
- External (bastion host) DNS server config: -
+ External (bastion host) DNS server config: +
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
@@ -511,9 +511,9 @@ zone "site2.example.com" {
};
- In the resolv.conf (or equivalent) on
- the bastion host(s):
-
resolv.conf (or equivalent) on
+ the bastion host(s):
+
search ...
nameserver 172.16.72.2
@@ -718,7 +718,7 @@ allow-update { key host1-host2. ;};
TKEY
is a mechanism for automatically generating a shared secret
between two hosts. There are several "modes" of
@@ -754,7 +754,7 @@ allow-update { key host1-host2. ;};
BIND 9 partially supports DNSSEC SIG(0)
transaction signatures as specified in RFC 2535 and RFC 2931.
@@ -815,7 +815,7 @@ allow-update { key host1-host2. ;};
The dnssec-keygen program is used to
generate keys.
@@ -871,7 +871,7 @@ allow-update { key host1-host2. ;};
The dnssec-signzone program is used
to sign a zone.
@@ -913,7 +913,7 @@ allow-update { key host1-host2. ;};
To enable named to respond appropriately
to DNS requests from DNSSEC aware clients,
@@ -1841,7 +1841,7 @@ $ dnssec-signzone -E '' -S example.net
BIND 9 fully supports all currently
defined forms of IPv6 name to address and address to name
diff --git a/doc/arm/Bv9ARM.ch05.html b/doc/arm/Bv9ARM.ch05.html
index a3a4c367ff..8fd537c5b0 100644
--- a/doc/arm/Bv9ARM.ch05.html
+++ b/doc/arm/Bv9ARM.ch05.html
@@ -44,13 +44,13 @@
Table of Contents
Traditionally applications have been linked with a stub resolver
library that sends recursive DNS queries to a local caching name
diff --git a/doc/arm/Bv9ARM.ch06.html b/doc/arm/Bv9ARM.ch06.html
index 6495cb42bf..4656e5fc7a 100644
--- a/doc/arm/Bv9ARM.ch06.html
+++ b/doc/arm/Bv9ARM.ch06.html
@@ -47,58 +47,56 @@
- Configuration File Elements
- Configuration File Grammar
-- acl Statement Grammar
+- acl Statement Grammar
- acl Statement Definition and
Usage
-- controls Statement Grammar
+- controls Statement Grammar
- controls Statement Definition and
Usage
-- include Statement Grammar
-- include Statement Definition and
+
- include Statement Grammar
+- include Statement Definition and Usage
+- key Statement Grammar
+- key Statement Definition and Usage
+- logging Statement Grammar
+- logging Statement Definition and Usage
+- lwres Statement Grammar
+- lwres Statement Definition and Usage
+- masters Statement Grammar
+- masters Statement Definition and
Usage
-- key Statement Grammar
-- key Statement Definition and Usage
-- logging Statement Grammar
-- logging Statement Definition and
- Usage
-- lwres Statement Grammar
-- lwres Statement Definition and Usage
-- masters Statement Grammar
-- masters Statement Definition and
- Usage
-- options Statement Grammar
+- options Statement Grammar
- options Statement Definition and
Usage
- server Statement Grammar
- server Statement Definition and
Usage
- statistics-channels Statement Grammar
-- statistics-channels Statement Definition and
+
- statistics-channels Statement Definition and
Usage
- trusted-keys Statement Grammar
-- trusted-keys Statement Definition
+
- trusted-keys Statement Definition
and Usage
-- managed-keys Statement Grammar
+- managed-keys Statement Grammar
- managed-keys Statement Definition
and Usage
- view Statement Grammar
-- view Statement Definition and Usage
+- view Statement Definition and Usage
- zone
Statement Grammar
-- zone Statement Definition and Usage
+- zone Statement Definition and Usage
- Zone File
+- Zone File
- Types of Resource Records and When to Use Them
-- Discussion of MX Records
+- Discussion of MX Records
- Setting TTLs
-- Inverse Mapping in IPv4
-- Other Zone File Directives
-- BIND Master File Extension: the $GENERATE Directive
+- Inverse Mapping in IPv4
+- Other Zone File Directives
+- BIND Master File Extension: the $GENERATE Directive
- Additional File Formats
- BIND9 Statistics
@@ -588,7 +586,7 @@
The BIND 9 comment syntax allows for
comments to appear
@@ -868,7 +866,7 @@
acl acl-name {
address_match_list
};
@@ -950,7 +948,7 @@
controls {
[ inet ( ip_addr | * ) [ port ip_port ]
allow { address_match_list }
@@ -1074,13 +1072,12 @@
include filename;
The include statement inserts the
specified file at the point where the include
@@ -1094,7 +1091,7 @@
key key_id {
algorithm algorithm_id;
secret secret_string;
@@ -1103,7 +1100,7 @@
The key statement defines a shared
secret key for use with TSIG (see the section called “TSIG”)
@@ -1148,7 +1145,7 @@
logging {
[ channel channel_name {
( file path_name
@@ -1172,8 +1169,7 @@
The logging statement configures a
wide
@@ -1206,7 +1202,7 @@
All log output goes to one or more channels;
you can make as many of them as you want.
@@ -1847,7 +1843,7 @@ category notify { null; };
The query-errors category is
specifically intended for debugging purposes: To identify
@@ -2075,7 +2071,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
This is the grammar of the lwres
statement in the named.conf file:
@@ -2091,7 +2087,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
The lwres statement configures the
name
@@ -2142,7 +2138,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
masters name [port ip_port] { ( masters_list |
ip_addr [port ip_port] [key key] ) ; [...] };
@@ -2150,7 +2146,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
masters
lists allow for a common set of masters to be easily used by
@@ -2160,7 +2156,7 @@ badresp:1,adberr:0,findfail:0,valfail:0]
This is the grammar of the options
statement in the named.conf file:
@@ -3966,7 +3962,7 @@ options {
The forwarding facility can be used to create a large site-wide
cache on a few servers, reducing traffic over links to external
@@ -4009,7 +4005,7 @@ options {
Dual-stack servers are used as servers of last resort to work
around
@@ -4277,7 +4273,7 @@ options {
The interfaces and ports that the server will answer queries
from may be specified using the listen-on option. listen-on takes
@@ -4751,7 +4747,7 @@ avoid-v6-udp-ports {};
use-v4-udp-ports,
avoid-v4-udp-ports,
@@ -4793,7 +4789,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
The server's usage of many system resources can be limited.
Scaled values are allowed when specifying resource limits. For
@@ -5150,7 +5146,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
- cleaning-interval
@@ -6082,7 +6078,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
BIND 9 provides the ability to filter
out DNS responses from external DNS servers containing
@@ -6205,7 +6201,7 @@ deny-answer-aliases { "example.net"; };
BIND 9 includes a limited
mechanism to modify DNS responses for requests
@@ -6472,7 +6468,7 @@ ns.domain.com.rpz-nsdname CNAME .
This feature is only available when BIND 9
is compiled with the --enable-rrl
@@ -6910,7 +6906,7 @@ ns.domain.com.rpz-nsdname CNAME .
The statistics-channels statement
@@ -6994,7 +6990,7 @@ ns.domain.com.rpz-nsdname CNAME .
The trusted-keys statement defines
@@ -7034,7 +7030,7 @@ ns.domain.com.rpz-nsdname CNAME .
managed-keys {
name initial-key flags protocol algorithm key-data ;
[ name initial-key flags protocol algorithm key-data ; [...]]
@@ -7172,7 +7168,7 @@ ns.domain.com.rpz-nsdname CNAME .
The view statement is a powerful
feature
@@ -7484,10 +7480,10 @@ zone zone_name [
The type keyword is required
for the zone configuration. Its
@@ -7814,7 +7810,7 @@ zone zone_name [
The zone's name may optionally be followed by a class. If
a class is not specified, class IN (for Internet),
@@ -7836,7 +7832,7 @@ zone zone_name [
- allow-notify
@@ -8708,7 +8704,7 @@ example.com. NS ns2.example.net.
@@ -9894,7 +9890,7 @@ example.com. NS ns2.example.net.
RRs are represented in binary form in the packets of the DNS
protocol, and are usually represented in highly encoded form
@@ -10097,7 +10093,7 @@ example.com. NS ns2.example.net.
As described above, domain servers store information as a
series of resource records, each of which contains a particular
@@ -10352,7 +10348,7 @@ example.com. NS ns2.example.net.
Reverse name resolution (that is, translation from IP address
to name) is achieved by means of the in-addr.arpa domain
@@ -10413,7 +10409,7 @@ example.com. NS ns2.example.net.
The Master File Format was initially defined in RFC 1035 and
has subsequently been extended. While the Master File Format
@@ -10428,7 +10424,7 @@ example.com. NS ns2.example.net.
When used in the label (or name) field, the asperand or
at-sign (@) symbol represents the current origin.
@@ -10439,7 +10435,7 @@ example.com. NS ns2.example.net.
Syntax: $ORIGIN
domain-name
@@ -10468,7 +10464,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
Syntax: $INCLUDE
filename
@@ -10504,7 +10500,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
Syntax: $TTL
default-ttl
@@ -10523,7 +10519,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
Syntax: $GENERATE
range
@@ -10953,7 +10949,7 @@ HOST-127.EXAMPLE. MX 0 .
Socket I/O statistics counters are defined per socket
types, which are
@@ -12241,7 +12237,7 @@ HOST-127.EXAMPLE. MX 0 .
Most statistics counters that were available
in BIND 8 are also supported in
diff --git a/doc/arm/Bv9ARM.ch07.html b/doc/arm/Bv9ARM.ch07.html
index 9a0c7d572e..9da5f94c64 100644
--- a/doc/arm/Bv9ARM.ch07.html
+++ b/doc/arm/Bv9ARM.ch07.html
@@ -45,10 +45,10 @@
Table of Contents
@@ -113,7 +113,7 @@ zone "example.com" {
On UNIX servers, it is possible to run BIND
@@ -139,7 +139,7 @@ zone "example.com" {
In order for a chroot environment
to
@@ -167,7 +167,7 @@ zone "example.com" {
Prior to running the named daemon,
use
diff --git a/doc/arm/Bv9ARM.ch08.html b/doc/arm/Bv9ARM.ch08.html
index ce913eafb5..66569b8604 100644
--- a/doc/arm/Bv9ARM.ch08.html
+++ b/doc/arm/Bv9ARM.ch08.html
@@ -44,15 +44,15 @@
Table of Contents
The Internet Systems Consortium
(ISC) offers a wide range
diff --git a/doc/arm/Bv9ARM.ch10.html b/doc/arm/Bv9ARM.ch10.html
index 3b8c3770cc..65da1270ca 100644
--- a/doc/arm/Bv9ARM.ch10.html
+++ b/doc/arm/Bv9ARM.ch10.html
@@ -43,115 +43,100 @@
-
-
-
+
+ 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 DNS implementations are
+ built.
+
- 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 DNS implementations are
- built.
-
+ The first working domain name server, called "Jeeves", was
+ written in 1983-84 by Paul Mockapetris for operation on DEC
+ Tops-20
+ machines located at the University of Southern California's
+ Information
+ Sciences Institute (USC-ISI) and SRI International's Network
+ Information
+ Center (SRI-NIC). A DNS server for
+ Unix machines, the Berkeley Internet
+ Name Domain (BIND) package, was
+ written soon after by a group of
+ graduate students at the University of California at Berkeley
+ under
+ a grant from the US Defense Advanced Research Projects
+ Administration
+ (DARPA).
+
- The first working domain name server, called "Jeeves", was
- written in 1983-84 by Paul Mockapetris for operation on DEC
- Tops-20
- machines located at the University of Southern California's
- Information
- Sciences Institute (USC-ISI) and SRI International's Network
- Information
- Center (SRI-NIC). A DNS server for
- Unix machines, the Berkeley Internet
- Name Domain (BIND) package, was
- written soon after by a group of
- graduate students at the University of California at Berkeley
- under
- a grant from the US Defense Advanced Research Projects
- Administration
- (DARPA).
-
-
-
-
+ Versions of BIND through
+ 4.8.3 were maintained by the Computer
+ Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
+ Painter, David Riggle and Songnian Zhou made up the initial BIND
+ project team. After that, additional work on the software package
+ was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
+ Corporation
+ employee on loan to the CSRG, worked on BIND for 2 years, from 1985
+ to 1987. Many other people also contributed to BIND development
+ during that time: Doug Kingston, Craig Partridge, Smoot
+ Carl-Mitchell,
+ Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently
+ handled by Mike Karels and Řivind Kure.
+
- Versions of BIND through
- 4.8.3 were maintained by the Computer
- Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark
- Painter, David Riggle and Songnian Zhou made up the initial BIND
- project team. After that, additional work on the software package
- was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment
- Corporation
- employee on loan to the CSRG, worked on BIND for 2 years, from 1985
- to 1987. Many other people also contributed to BIND development
- during that time: Doug Kingston, Craig Partridge, Smoot
- Carl-Mitchell,
- Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently
- handled by Mike Karels and Řivind Kure.
-
+ BIND versions 4.9 and 4.9.1 were
+ released by Digital Equipment
+ Corporation (now Compaq Computer Corporation). Paul Vixie, then
+ a DEC employee, became BIND's
+ primary caretaker. 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.
+
- BIND versions 4.9 and 4.9.1 were
- released by Digital Equipment
- Corporation (now Compaq Computer Corporation). Paul Vixie, then
- a DEC employee, became BIND's
- primary caretaker. 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.
-
+ In 1994, BIND version 4.9.2 was sponsored by
+ Vixie Enterprises. Paul
+ Vixie became BIND's principal
+ architect/programmer.
+
- In 1994, BIND version 4.9.2 was sponsored by
- Vixie Enterprises. Paul
- Vixie became BIND's principal
- architect/programmer.
-
+ BIND versions from 4.9.3 onward
+ have been developed and maintained
+ by the Internet Systems Consortium and its predecessor,
+ the Internet Software Consortium, with support being provided
+ by ISC's sponsors.
+
- BIND 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.
-
+ As co-architects/programmers, Bob Halley and
+ Paul Vixie released the first production-ready version of
+ BIND version 8 in May 1997.
+
- As co-architects/programmers, Bob Halley and
- Paul Vixie released the first production-ready version of
- BIND version 8 in May 1997.
-
+ BIND version 9 was released in September 2000 and is a
+ major rewrite of nearly all aspects of the underlying
+ BIND architecture.
+
- BIND version 9 was released in September 2000 and is a
- major rewrite of nearly all aspects of the underlying
- BIND architecture.
-
+ BIND versions 4 and 8 are officially deprecated.
+ No additional development is done
+ on BIND version 4 or BIND version 8.
+
- BIND versions 4 and 8 are officially deprecated.
- No additional development is done
- on BIND version 4 or BIND version 8.
-
-
- BIND development work is made
- possible today by the sponsorship
- of several corporations, and by the tireless work efforts of
- numerous individuals.
-
-
+ BIND development work is made
+ possible today by the sponsorship
+ of several corporations, and by the tireless work efforts of
+ numerous individuals.
+
@@ -467,7 +467,7 @@
diff --git a/doc/arm/Bv9ARM.html b/doc/arm/Bv9ARM.html
index 3c6821ff4e..90f1d442a9 100644
--- a/doc/arm/Bv9ARM.html
+++ b/doc/arm/Bv9ARM.html
@@ -50,39 +50,39 @@
- 1. Introduction
- 2. BIND Resource Requirements
- 3. Name Server Configuration
- 4. Advanced DNS Features
@@ -91,8 +91,8 @@
- Dynamic Update
- Incremental Zone Transfers (IXFR)
-- Split DNS
-- Split DNS
+- TSIG
- Generate Shared Keys for Each Pair of Hosts
@@ -102,13 +102,13 @@
- TSIG Key Based Access Control
- Errors
- TKEY
-- SIG(0)
+- TKEY
+- SIG(0)
- DNSSEC
- DNSSEC, Dynamic Zones, and Automatic Signing
- IPv6 Support in BIND 9
+- IPv6 Support in BIND 9
- Address Lookups Using AAAA Records
- Address to Name Lookups Using Nibble Format
@@ -148,7 +148,7 @@
- 5. The BIND 9 Lightweight Resolver
- 6. BIND 9 Configuration Reference
@@ -156,58 +156,56 @@
- Configuration File Elements
- Configuration File Grammar
-- acl Statement Grammar
+- acl Statement Grammar
- acl Statement Definition and
Usage
-- controls Statement Grammar
+- controls Statement Grammar
- controls Statement Definition and
Usage
-- include Statement Grammar
-- include Statement Definition and
+
- include Statement Grammar
+- include Statement Definition and Usage
+- key Statement Grammar
+- key Statement Definition and Usage
+- logging Statement Grammar
+- logging Statement Definition and Usage
+- lwres Statement Grammar
+- lwres Statement Definition and Usage
+- masters Statement Grammar
+- masters Statement Definition and
Usage
-- key Statement Grammar
-- key Statement Definition and Usage
-- logging Statement Grammar
-- logging Statement Definition and
- Usage
-- lwres Statement Grammar
-- lwres Statement Definition and Usage
-- masters Statement Grammar
-- masters Statement Definition and
- Usage
-- options Statement Grammar
+- options Statement Grammar
- options Statement Definition and
Usage
- server Statement Grammar
- server Statement Definition and
Usage
- statistics-channels Statement Grammar
-- statistics-channels Statement Definition and
+
- statistics-channels Statement Definition and
Usage
- trusted-keys Statement Grammar
-- trusted-keys Statement Definition
+
- trusted-keys Statement Definition
and Usage
-- managed-keys Statement Grammar
+- managed-keys Statement Grammar
- managed-keys Statement Definition
and Usage
- view Statement Grammar
-- view Statement Definition and Usage
+- view Statement Definition and Usage
- zone
Statement Grammar
-- zone Statement Definition and Usage
+- zone Statement Definition and Usage
- Zone File
+- Zone File
- Types of Resource Records and When to Use Them
-- Discussion of MX Records
+- Discussion of MX Records
- Setting TTLs
-- Inverse Mapping in IPv4
-- Other Zone File Directives
-- BIND Master File Extension: the $GENERATE Directive
+- Inverse Mapping in IPv4
+- Other Zone File Directives
+- BIND Master File Extension: the $GENERATE Directive
- Additional File Formats
- BIND9 Statistics
@@ -219,19 +217,19 @@
- 7. BIND 9 Security Considerations
- 8. Troubleshooting
- A. Release Notes
@@ -249,10 +247,6 @@
- B. A Brief History of the DNS and BIND
-- C. General DNS Reference Information
- D. BIND 9 DNS Library Support