ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

ARM update

Browse Source
This commit is contained in:
Bob Halley
2000-03-23 22:32:00 +00:00
parent 1872808932
commit 811fb0d705
11 changed files with 3536 additions and 1768 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
doc/arm/BV9ARM.1.html
View File

@@ -7,12 +7,12 @@
<BODY BGCOLOR="#ffffff">
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997350">
<A NAME="pgfId=1007883">
</A>
Section 1. Introduction </H1>
</OL>
<P CLASS="1LevelContinued">
<A NAME="pgfId=997351">
<A NAME="pgfId=1007884">
</A>
The Internet Domain Name System (DNS) consists of the syntax to specify the names of entities in the Internet in a hierarchical manner, the rules used for delegating authority over names, and the system implementation that actually maps names to Internet addresses. DNS data is maintained in a group of distributed hierarchical databases.</P>
<DIV>
@@ -130,8 +130,7 @@ Literal user input</P>
<P CLASS="CellBody2">
<A NAME="pgfId=997373">
</A>
<KBD CLASS="Literal-user-input">
Courier Bold</KBD>
Courier Bold
</P>
</TD>
</TR>
@@ -406,7 +405,7 @@ terminal</EM>
subdomains</EM>
. Every subdomain is a domain and every domain except the root is also a subdomain. The terminology is not intuitive and it is suggested that you read RFCs 1033, 1034, and 1035 to gain a complete understanding of this difficult and subtle topic.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997425">
<A NAME="pgfId=1007878">
</A>
Though BIND is a Domain Nameserver, it deals primarily in terms of zones. The primary and secondary declarations in the <CODE CLASS="Program-Process">
named.conf</CODE>
@@ -440,13 +439,13 @@ root</EM>
</A>
Any servers listed in the NS records must be configured as <A NAME="marker=997427">
</A>
authoritative for the zone. A server is authoritative for a zone when it has been configured to answer questions for that zone with authority, which it does by setting the &quot;authoritative answer&quot; (AA) bit in reply brackets. A server may be authoritative for more than one zone. The authoritative data for a zone is composed of all of the Resource Records (RRs)--the data associated with names in a tree-structured name space--attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above <A NAME="marker=997429">
authoritative for the zone. A server is authoritative for a zone when it has been configured to answer questions for that zone with authority, which it does by setting the &quot;authoritative answer&quot; (AA) bit in reply packets. A server may be authoritative for more than one zone. The authoritative data for a zone is composed of all of the Resource Records (RRs)--the data associated with names in a tree-structured name space--attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above <A NAME="marker=997429">
</A>
cuts around the bottom edge of the zone.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997430">
</A>
Adding a zone as a type primary or type slave will tell the server to answer questions for the zone authoritatively. If the server is able to load the zone into memory without any errors it will set the AA bit when it replies to queries for the zone. See RFCs 1034 and 1035 for more information about the AA bit.</P>
Adding a zone as a type master or type slave will tell the server to answer questions for the zone authoritatively. If the server is able to load the zone into memory without any errors it will set the AA bit when it replies to queries for the zone. See RFCs 1034 and 1035 for more information about the AA bit.</P>
</DIV>
<DIV>
<OL>
@@ -458,13 +457,13 @@ Adding a zone as a type primary or type slave will tell the server to answer que
<P CLASS="3LevelContinued">
<A NAME="pgfId=997432">
</A>
A DNS server can be primary for some zones and secondary for others or can be only a primary, or only a secondary, or can serve no zones and just answer queries via its <EM CLASS="Emphasis">
A DNS server can be master for some zones and slave for others or can be only a master, or only a slave, or can serve no zones and just answer queries via its <EM CLASS="Emphasis">
cache</EM>
. Primary servers are often also called <EM CLASS="Emphasis">
masters</EM>
and secondary servers are often also called <EM CLASS="Emphasis">
slaves</EM>
. Both primary/master and secondary/slave servers are authoritative for a zone.</P>
. Master servers are often also called <EM CLASS="Emphasis">
primaries</EM>
and slave servers are often also called <EM CLASS="Emphasis">
secondaries</EM>
. Both master/primary and slave/secondary servers are authoritative for a zone.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997433">
</A>
@@ -527,11 +526,11 @@ Instead of interacting with the nameservers for the root and other domains, a <E
forwarding server</EM>
always forwards queries it cannot satisfy from its authoritative data or cache to a fixed list of other servers. The forwarded queries are also known as <EM CLASS="Emphasis">
recursive queries, </EM>
the same type as a client would send to a server. There may be one or more servers forwarded to for a given zone and they are queried in turn until the list is exhausted. A forwarding server is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers, and an internet firewall. The servers which cannot pass packets through the firewall would forward to the server which can, which would ask the internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. </P>
the same type as a client would send to a server. There may be one or more servers forwarded to, and they are queried in turn until the list is exhausted or an answer is found. A forwarding server is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers, and an internet firewall. The servers which cannot pass packets through the firewall would forward to the server which can, which would ask the internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of. </P>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997442">
</A>
There is no prohibition against declaring a server to be a forwarder even though it has primary and/or secondary zones as well; the effect will still be that anything in the local server's cache or zones will be answered, and anything else will be forwarded using the forwarders list.</P>
There is no prohibition against declaring a server to be a forwarder even though it has master and/or slave zones as well; the effect will still be that anything in the local server's cache or zones will be answered, and anything else will be forwarded using the forwarders list.</P>
</DIV>
<DIV>
<OL>
@@ -540,23 +539,30 @@ There is no prohibition against declaring a server to be a forwarder even though
</A>
1.4.3.5 Stealth Server</H5>
</OL>
<!--
[[P CLASS="comment"]]
[[A NAME="pgfId=997445"]]
[[/A]]
A [[A NAME="marker=997444"]]
[[/A]]
stealth server is a primary master server that is neither listed in any root zone files nor advertised as being a server. It is set up to hide the true master server for a zone in order to provide some measure of security, or protect the zone from [[A NAME="marker=997446"]]
[[/A]]
Denial of Service ([[A NAME="marker=997447"]]
[[/A]]
DoS) attacks, or reduce the load on the main server, or any number of other reasons. It is also used to provide some measure of network redundancy. Slave servers load zone data from it.[[/P]]
[[P CLASS="4LevelContinued"]]
[[A NAME="pgfId=997347"]]
[[/A]]
-->
<P CLASS="4LevelContinued">
<A NAME="pgfId=997445">
</A>
A <A NAME="marker=997444">
</A>
stealth server is a primary master server that is neither listed in any root zone files nor advertised as being a server. It is set up to hide the true master server for a zone in order to provide some measure of security, or protect the zone from <A NAME="marker=997446">
</A>
Denial of Service (<A NAME="marker=997447">
</A>
DoS) attacks, or reduce the load on the main server, or any number of other reasons. It is also used to provide some measure of network redundancy. Slave servers load zone data from it.</P>
A stealth server is a server that answers authoritatively for a zone, but is not listed in that zone's NS records. Stealth servers can be used as a way to centralise distribution of a zone, without having to edit the zone on a remote nameserver. Where the master file for a zone resides on a stealth server in this way, it often referred to as a 'hidden primary' configuration. Stealth servers can also be a way to keep a local copy of a zone for rapid access to the zone's records, even if all 'official' nameservers for the zone are inaccessable.</P>
<P CLASS="Body">
<A NAME="pgfId=997347">
<A NAME="pgfId=1007863">
</A>
&nbsp;</P>
</DIV>
</DIV>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
</BODY>
</HTML>

66
doc/arm/BV9ARM.2.html
View File

@@ -8,93 +8,93 @@
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997350">
</A>
</A>
Section 2. BIND Resource Requirements</H1>
</OL>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997351">
</A>
</A>
2.1 Hardware requirements</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997352">
</A>
DNS hardware requirements have traditionally been quite modest. For many installations, servers that have been pensioned off from active duty have performed admirably as DNS servers. </P>
</A>
DNS hardware requirements have traditionally been quite modest. For many installations, servers that have been pensioned off from active duty have performed admirably as DNS servers.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997353">
</A>
</A>
The DNSSEC and IPv6 features of BINDv9 may prove to be quite CPU intensive however, so organizations that make heavy use of these features may wish to consider larger systems for these applications. BINDv9 is now fully multithreaded, allowing full utilization of multiprocessor systems, for installations that need it.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997354">
</A>
</A>
2.2 CPU Requirements</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997355">
</A>
CPU requrements for BINDv9 start at i486 for serving of static zones without caching, to enterprise-class machines if you intend to process many dynamic updates and DNSSEC signed zones, serving many thousands of queries per second.</P>
</A>
CPU requirements for BINDv9 range from i486-class machines for serving of static zones without caching, to enterprise-class machines if you intend to process many dynamic updates and DNSSEC signed zones, serving many thousands of queries per second.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997356">
</A>
</A>
2.3 Memory Requirements </H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997357">
</A>
For BIND 8.x and older versions, the memory of the server had to be large enough to fit the cache and zones loaded off disk. BINDv9 will provide methods to set resource limits, at the expense of limiting the cache and causing more DNS traffic. It is still good practice to have enough memory to load all zone and cache data into memory--unfortunately, the best way to determine this for a given installation is to watch the nameserver in operation. After a few weeks, the server process should reach a relatively stable size where entries are expiring from the cache as fast as they are being inserted. Ideally, the resource limits for BINDv9 should be set higher than this stable size.</P>
</A>
The memory of the server has to be large enough to fit the cache and zones loaded off disk. Future releases of BINDv9 will provide methods to limit the amount of memory used by the cache, at the expense of reducing cache hit rates and causing more DNS traffic. It is still good practice to have enough memory to load all zone and cache data into memory--unfortunately, the best way to determine this for a given installation is to watch the nameserver in operation. After a few weeks, the server process should reach a relatively stable size where entries are expiring from the cache as fast as they are being inserted. Ideally, the resource limits should be set higher than this stable size.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997358">
</A>
</A>
2.4 Nameserver Intensive Environment Issues</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997359">
</A>
</A>
For nameserver intensive environments, there are two alternative configurations that may be used. The first is where clients and any second-level internal nameservers query a main nameserver, which has enough memory to build a large cache. This approach minimizes the bandwidth used by external name lookups. The second alternative is to set up second-level internal nameservers to make queries independently. In this configuration, none of the individual machines needs to have as much memory or CPU power as in the first alternative, but this has the disadvantage of making many more external queries, as none of the nameservers share their cached data.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997360">
</A>
</A>
2.5 Operating Systems Supported by the Internet Software Consortium</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997361">
</A>
</A>
ISC BINDv9 compiles and runs on the following operating systems:</P>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997362"> </A>
IBM AIX 4.3</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997363"> </A>
Compaq Digital/Tru64 UNIX 4.0, 5.0</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997364"> </A>
HP HP-UX 11.0</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997365"> </A>
SGI IRIX 6.4</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997366"> </A>
Red Hat Linux 6.0, 6.1</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997367"> </A>
Sun Solaris 2.6, 7</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997368"> </A>
FreeBSD 3.3</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997369"> </A>
NetBSD 1.4.1 or 1.4.2, with MIT pthreads</PRE>
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997362"></A>
IBM AIX 4.3
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997363"></A>
Compaq Digital/Tru64 UNIX 4.0D
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997364"></A>
HP HP-UX 11
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997365"></A>
IRIX64 6.5
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997366"></A>
Red Hat Linux 6.0, 6.1
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997367"></A>
Sun Solaris 2.6, 7, 8 (beta)
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997368"></A>
FreeBSD 3.4-STABLE
<PRE CLASS="2Level-fixed"><A NAME="pgfId=997369"></A>
NetBSD-current with &quot;unproven&quot; pthreads</PRE>
<P CLASS="Body">
<A NAME="pgfId=997347">
</A>
</A>
&nbsp;</P>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</BODY>
</HTML>

32
doc/arm/BV9ARM.3.html
View File

@@ -305,7 +305,7 @@ also-notify</CODE>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997465">
</A>
There are several indispensable diagnostic, administrative and monotoring tools available to the system administrator for controlling and debugging the nameserver daemon. We describe several in this section </P>
There are several indispensable diagnostic, administrative and monitoring tools available to the system administrator for controlling and debugging the nameserver daemon. We describe several in this section </P>
<DIV>
<OL>
<H5 CLASS="4Level">
@@ -359,7 +359,7 @@ The<EM CLASS="pathname">
host</CODE>
<EM CLASS="pathname">
</EM>
utility provides a simple DNS lookup using a command-line interface for looking up Internet hostnames. Bu default, the utility interprets between host names and Internet addresses, but its functionality can be extended with the use of options.</P>
utility provides a simple DNS lookup using a command-line interface for looking up Internet hostnames. By default, the utility converts between host names and Internet addresses, but its functionality can be extended with the use of options.</P>
</DIV>
<DIV>
<H5 CLASS="Subhead4">
@@ -423,25 +423,27 @@ Administrative tools play an integral part in the management of a server.</P>
<H5 CLASS="Subhead4">
<A NAME="pgfId=997489">
</A>
ndc</H5>
rndc</H5>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997490">
</A>
The name daemon control (<CODE CLASS="Program-Process">
ndc</CODE>
) program is a shell script utility that allows the system administrator to control the operation of a nameserver. If you run ndc without any options it will display a usage message and prompt for commands until it reads EOF. Several commands are built into ndc, but the full set of commands supported by the nameserver is dynamic and should be discovered using the &quot;help&quot; command. Read the man page for ndc for details on its command syntax.</P>
</DIV>
<DIV>
<H5 CLASS="Subhead4">
<A NAME="pgfId=997491">
The remote name daemon control (<CODE CLASS="Program-Process">
rndc</CODE>
) program is a program that allows the system administrator to control the operation of a nameserver. If you run rndc without any options it will display a usage message.</P>
<P CLASS="4LevelContinued">
<A NAME="pgfId=1012780">
</A>
Usage:</H5>
<PRE CLASS="4Level-fixed1"><A NAME="pgfId=997492"></A>
ndc [-c channel] [-l localsock] [-p pidfile] [-d] [-q] [-s] [-t] [command]</PRE>
Usage:</P>
<P CLASS="4LevelContinued">
<A NAME="pgfId=1012777">
</A>
<CODE CLASS="Program-Process">
rndc [-p port] [-m] server command [command ...]</CODE>
</P>
<P CLASS="4LevelContinued">
<A NAME="pgfId=997493">
</A>
For more information and a list of available commands and options, see the ndc man page.</P>
For more information and a list of available commands and options, see the rndc man page.</P>
</DIV>
<DIV>
<OL>
@@ -468,7 +470,7 @@ MRTG</CODE>
&nbsp;</P>
</DIV>
</DIV>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
</BODY>
</HTML>

671
doc/arm/BV9ARM.4.html
View File

File diff suppressed because it is too large Load Diff

2584
doc/arm/BV9ARM.5.html
View File

File diff suppressed because it is too large Load Diff

106
doc/arm/BV9ARM.6.html
View File

@@ -8,56 +8,58 @@
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997350">
</A>
</A>
Section 6. Security Considerations</H1>
</OL>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997352">
</A>
</A>
6.1 <A NAME="32222">
</A>
</A>
Access Control Lists</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997353">
</A>
</A>
Access Control Lists (ACLs), are address match lists that you can set up and nickname for future use in <CODE CLASS="Program-Process">
allow-query</CODE>
, <CODE CLASS="Program-Process">
allow-recursion</CODE>
, <CODE CLASS="Program-Process">
blackhole allow-transfer</CODE>
blackhole</CODE>
, <CODE CLASS="Program-Process">
allow-transfer</CODE>
, etc.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997354">
</A>
</A>
Using ACLs allows you to have finer control over who can access your nameserver, without cluttering up your config files with huge lists of IP addresses.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997355">
</A>
</A>
It is a <EM CLASS="Emphasis">
good idea</EM>
to use ACLs, and to control access to your server. Limiting access to your server by outside parties can help prevent spoofing and DoS attacks against your server.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997356">
</A>
</A>
Here is an example of how to properly apply ACLs:</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997357">
</A>
</A>
// Set up an ACL named &quot;bogusnets&quot; that will block RFC1918 space,<BR>
// which is commonly used in spoofing attacks.</P>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"></A>
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997359">
</A>
</A>
// Set up an ACL called our-nets. Replace this with the real IP numbers.</P>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997360"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997360"></A>
acl our-nets { x.x.x.x/24; x.x.x.x/21; }; </PRE>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997361"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997361"></A>
options {
...
...
@@ -67,7 +69,7 @@ options {
blackhole { bogusnets; };
...
};</PRE>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"></A>
zone &quot;example.com&quot; {
type master;
file &quot;m/example.com&quot;;
@@ -75,11 +77,11 @@ zone &quot;example.com&quot; {
};</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997363">
</A>
</A>
This allows recursive queries of the server from the outside unless recursion has been previously disabled.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997364">
</A>
</A>
For more information on how to use ACLs to protect your server, see the <EM CLASS="Emphasis">
AUSCERT</EM>
advisory at<BR>
@@ -91,16 +93,16 @@ ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos</EM>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997365">
</A>
</A>
6.2 <CODE CLASS="Program-Process">
chroot</CODE>
and <CODE CLASS="Program-Process">
set_uid</CODE>
setuid</CODE>
(for UNIX servers)</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997366">
</A>
</A>
On UNIX servers, it is possible to run BIND in a <EM CLASS="Emphasis">
chrooted</EM>
environment (<CODE CLASS="Program-Process">
@@ -110,13 +112,15 @@ chroot()</CODE>
&quot; option. This can help improve system security by placing BIND in a &quot;sandbox,&quot; which will limit the damage done if a server is compromised.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997367">
</A>
Another useful feature in the UNIX version of BIND is the ability to run the daemon as a nonprivileged user ( -u &lt;user&gt; ) and in a nonprivileged group ( -g &lt;group&gt; ). We suggest running as a nonpriveleged user when using the <CODE CLASS="Program-Process">
</A>
Another useful feature in the UNIX version of BIND is the ability to run the daemon as a nonprivileged user ( <CODE CLASS="Program-Process">
-u</CODE>
&lt;user&gt; ). We suggest running as a nonprivileged user when using the <CODE CLASS="Program-Process">
chroot</CODE>
feature.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997368">
</A>
</A>
Here is an example command line to load BIND in a <CODE CLASS="Program-Process">
chroot()</CODE>
sandbox, <BR>
@@ -125,34 +129,36 @@ chroot()</CODE>
, and to run <CODE CLASS="Program-Process">
named</CODE>
<CODE CLASS="Program-Process">
set_uid</CODE>
and <CODE CLASS="Program-Process">
set_gid</CODE>
it to user 202 and group 202:</P>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997369"> </A>
/usr/local/bin/named -u 202 -g 202 -t /var/named</PRE>
setuid</CODE>
to user 202:</P>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997369"></A>
/usr/local/bin/named -u 202 -t /var/named</PRE>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997370">
</A>
</A>
6.2.1 The <CODE CLASS="Program-Process">
chroot</CODE>
environment</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997371">
</A>
</A>
In order for a <CODE CLASS="Program-Process">
chroot()</CODE>
environment to work properly in a particular directory (e.g. var/named), you will need to set up an environment that includes everything BIND needs to run. From BIND's point of view, /var/named is the root of the filesystem. You will need <CODE CLASS="Program-Process">
/dev/null</CODE>
environment to work properly in a particular directory (e.g. <EM CLASS="pathname">
/var/named</EM>
), you will need to set up an environment that includes everything BIND needs to run. From BIND's point of view, <EM CLASS="pathname">
/var/named</EM>
is the root of the filesystem. You will need <EM CLASS="pathname">
/dev/null</EM>
, and any library directories and files that BIND needs to run on your system. Please consult your operating system's instructions if you need help figuring out which library files you need to copy over to the <CODE CLASS="Program-Process">
chroot()</CODE>
sandbox.</P>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997372">
</A>
</A>
If you are running an operating system that supports static binaries, you can also compile BIND staticly and avoid the need to copy system libraries over to your <CODE CLASS="Program-Process">
chroot()</CODE>
sandbox.</P>
@@ -161,16 +167,14 @@ chroot()</CODE>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997373">
</A>
</A>
6.2.2 Using <CODE CLASS="Program-Process">
set_uid</CODE>
/<CODE CLASS="Program-Process">
set_gid</CODE>
setuid</CODE>
</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997374">
</A>
</A>
Prior to running the <CODE CLASS="Program-Process">
named</CODE>
daemon, use the <CODE CLASS="Program-Process">
@@ -184,30 +188,18 @@ chown</CODE>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997375">
</A>
</A>
6.3 Dynamic updates</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997376">
</A>
Since dynamic updates do not have per-RR security, access to the dynamic update facility should be strictly limited. The traditional way to do this has been host-based, but BINDv9 allows tranaction signature (TSIG) signed updates to cryptographically verify the updates.</P>
</A>
Access to the dynamic update facility should be strictly limited. In earlier versions of BIND the only way to do this was based on the IP address of the host requesting the update. BINDv9 also supports authenticating updates cryptographically by means of transaction signatures (TSIG). The use of TSIG is strongly recommended.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1002128">
</A>
<EM CLASS="Emphasis">
(Note: The syntax for this not finalized.)</EM>
</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1002129">
</A>
See also <A HREF="BV9ARM.4.html#19780" CLASS="XRef">
Incremental Transfer (IXFR)</A>
.</P>
<P CLASS="Body">
<A NAME="pgfId=997347">
</A>
&nbsp;</P>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
<A NAME="pgfId=1006806">
</A>
Some sites choose to keep all dynamically updated DNS data in a subdomain and delegate that subdomain to a separate zone. This way, the top-level zone containing critical data such as the IP addresses of public web and mail servers need not allow dynamic update at all.</P>
</DIV>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</BODY>
</HTML>

104
doc/arm/BV9ARM.7.html
View File

@@ -8,150 +8,150 @@
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997350">
</A>
</A>
Section 7. Troubleshooting</H1>
</OL>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997351">
</A>
</A>
7.1 Common Log Messages and What They Mean</H3>
</OL>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997352">
</A>
</A>
lame server</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997353"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997353"></A>
ns named[111]: Lame server on 'www.foo.com' (in 'foo.com'?): [192.168.0.2].53 'ns2.foo.com'</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997354">
</A>
</A>
This is a harmless error message. It means that the server at 192.168.0.2 (ns2.foo.com) is listed as a nameserver for &quot;foo.com&quot;, but it doesn't really know anything about foo.com.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997355">
</A>
</A>
If this is a zone under your control, check each of the nameservers to ensure that they are configured to answer questions properly.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997356">
</A>
</A>
If it's a zone out on the Internet, it would be nice to notify the owners of the domain in question so that they can take a look at it. In practice, though, not many people have time to do this.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997357">
</A>
</A>
bad referral</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997358"></A>
ns named[111]: bad referral (other.com !&lt; subdomain.other.com)</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997359">
</A>
</A>
This indicates that your nameserver (ns.foo.com) queried the nameserver for foo2.com to find out how to get to subdomain.foo2.com. foo2.com told your nameserver that subdomain.foo2.com was delegated to some other.foo2.com, so your nameserver queried that.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997360">
</A>
</A>
someother.foo2.com didn't think that subdomain.foo2.com had been delegated to it, so it referred your server (ns.foo.com) back to the foo2.com nameserver.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997361">
</A>
</A>
not authoritative for</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997362"></A>
ns named-xfer[111]: [192.168.0.1] not authoritative for foo.com, SOA query got rcode 0, aa 0, ancount 1, aucount 0</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997363">
</A>
</A>
This error usually shows up on a slave server. It indicates that the master server is not answering authoritatively for the zone. This usually happens when the zone is rejected (while named is loading) on the master server. Check the logs on the master server. If ancount -- 0, you may be pointing at the wrong master server for the zone.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997364">
</A>
</A>
rejected zone</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997365"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997365"></A>
ns named[111]: master zone &quot;foo.com&quot; (IN) rejected due to errors (serial111)</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997366">
</A>
</A>
This indicates that the foo.com zone was rejected because of an error in the zone file. Check the lines above this error -- named will usually tell you what it didn't like and where to find it in the zone file.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997367">
</A>
</A>
no NS RRs found</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997368"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997368"></A>
ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): no NS RRs found at zonetop</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997369">
</A>
</A>
The foo.com.db file is missing NS records at the top of the zone (in the SOA section). Check to make sure they exist and that there is white space (spaces or tabs) in front of them. White spaces matter here.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997370">
</A>
</A>
no default TTL set</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997371"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997371"></A>
ns named[111]: Zone &quot;foo.com&quot; (file foo.com.db): No default TTL set using SOA minimum instead</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997372">
</A>
</A>
You need to add a $TTL to the top of the foo.com.db zone file. See RFC2308, or section 3.2.3, &quot;Setting TTLs&quot; in this document, for information on how to use $TTL.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997373">
</A>
</A>
no root nameserver for class</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997374"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997374"></A>
findns: No root nameservers for class IN?</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997375">
</A>
</A>
Your nameserver is having problems finding the root nameservers. Check your root hints file to make sure it is not corrupted. Also, make sure that your nameserver can reach the Internet.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997376">
</A>
</A>
If you are running an internal root nameserver, make sure it's configured properly and is answering queries.</P>
</DIV>
<DIV>
<UL>
<H6 CLASS="Subhead2">
<A NAME="pgfId=997377">
</A>
</A>
address already in use</H6>
</UL>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997378"> </A>
<PRE CLASS="2Level-fixed1"><A NAME="pgfId=997378"></A>
ctl_server: bind: Address already in use</PRE>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997379">
</A>
</A>
This usually indicates that another copy of BIND is already running. Verify that you have killed old copies of the daemon.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997380">
</A>
</A>
This can also pop up if you originally ran named as &quot;root&quot; and now run it as a regular user. named may have left behind an ndc control socket that is owned by root if it crashed, or was not killed gracefully.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997381">
</A>
</A>
This means that the regular user wouldn't be able to delete it, so it would think named is still running. The solution is to remove any ndc sockets in /usr/local/etc, or /var/run, etc.</P>
</DIV>
</DIV>
@@ -159,20 +159,20 @@ This means that the regular user wouldn't be able to delete it, so it would thin
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997382">
</A>
</A>
7.2 Common Problems</H3>
</OL>
<DIV>
<OL>
<H4 CLASS="3Level">
<A NAME="pgfId=997383">
</A>
</A>
7.2.1 It's not working; how can I figure out what's wrong?</H4>
</OL>
<P CLASS="3LevelContinued">
<A NAME="pgfId=997384">
</A>
The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in <A HREF="BV9ARM.3.html#30164" CLASS="XRef">
</A>
The best solution to solving installation and configuration issues is to take preventative measures by setting up logging files beforehand (see the sample configurations in <A HREF="BvARM.3.html#30164" CLASS="XRef">
Sample Configuration and Logging</A>
). The log files provide a source of hints and information that can be used to figure out what went wrong and how to fix the problem.</P>
</DIV>
@@ -181,47 +181,49 @@ Sample Configuration and Logging</A>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997388">
</A>
</A>
7.3 Incrementing and Changing the Serial Number</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997389">
</A>
Zone serial numbers are just numbers--they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. A number of people have been testing these numbers for Y2K compliance and have set the number to the year 2000 to see if it will work. They then try to restore the old serial number. This will cause problems with BIND, because serial numbers are used to indicate that a zone has been updated. If the serial number on the secondary server is lower than the serial number on the primary, the secondary server will attempt to update its copy of the zone.</P>
<A NAME="pgfId=1001230">
</A>
Zone serial numbers are just numbers--they aren't date related. A lot of people set them to a number that represents a date, usually of the form YYYYMMDDRR. A number of people have been testing these numbers for Y2K compliance and have set the number to the year 2000 to see if it will work. They then try to restore the old serial number. This will cause problems, because serial numbers are used to indicate that a zone has been updated. If the serial number on the secondary server is lower than the serial number on the primary, the secondary server will attempt to update its copy of the zone.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997390">
</A>
</A>
Setting the serial number to a lower number on the primary server than the secondary server means that the secondary will not perform updates to its copy of the zone.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997391">
</A>
</A>
The solution to this is to add 2147483647 (2^31-1) to the number, reload the zone and make sure all secondaries have updated to the new zone serial number, then reset the number to what you want it to be, and reload the zone again.</P>
</DIV>
<DIV>
<OL>
<H3 CLASS="2Level">
<A NAME="pgfId=997392">
</A>
</A>
7.4 Where Can I Get Help?</H3>
</OL>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997393">
</A>
</A>
The Internet Software Consortium (ISC) offers a wide range of support and service agreements for BIND, DHCP and INN servers. Four levels of premium support are available and each level includes support for all ISC programs, significant discounts on products and training, and a recognized priority on bug fixes and non-funded feature requests. In addition, ISC offers a standard support agreement package which includes services ranging from bug fix announcements to remote support. It also includes training in BIND, DHCP or INN.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=997394">
</A>
</A>
To discuss arrangements for support, contact
<A HREF="mailto:clientservices@isc.org">clientservices@isc.org</A>
or visit the ISC web page at<BR>
<EM CLASS="URL">
<A HREF="http://www.isc.org/services/support/">http://www.isc.org/services/support/</A></EM>
<a href="mailto: info@isc.org">info@isc.org</A></CODE>
or visit the ISC web page at
<a href="http://www.isc.org/services/support/">the ISC web site</A></EM>
to read more.</P>
<P CLASS="Body">
<A NAME="pgfId=997347">
</A>
</A>
&nbsp;</P>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
</DIV>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
</BODY>
</HTML>

179
doc/arm/BV9ARM.8.html
View File

@@ -3,120 +3,120 @@
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
<LINK REL="STYLESHEET" HREF="BV9ARM.css">
<TITLE> Section 7. Troubleshooting</TITLE></HEAD>
<TITLE> Appendices</TITLE></HEAD>
<BODY BGCOLOR="#ffffff">
<OL>
<H1 CLASS="1Level">
<A NAME="pgfId=997347">
</A>
<A NAME="pgfId=997350">
</A>
Appendices</H1>
</OL>
<DIV>
<H3 CLASS="AppendixLevel1">
<A NAME="pgfId=999043">
</A>
</A>
Appendix A. Acknowledgements</H3>
<DIV>
<H4 CLASS="AppendixLevel2">
<A NAME="pgfId=1000953">
</A>
</A>
A Brief History of the DNS and BIND</H4>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000944">
</A>
</A>
Although the &quot;official&quot; 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, &quot;Domain Names-Concepts and Facilities,&quot; and RFC 1035, &quot;Domain Names-Implementation and Specification&quot; were published and became the standards upon which all DNS implementations are built.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000945">
</A>
</A>
The first working domain name server, called &quot;Jeeves,&quot; was written in 1983-84 by Paul Mockapetris for operation on DEC Tops-20 machines located at the University of Southern California's Information Sciences Institute (USC-ISI) and SRI International's Network Information Center (SRI-NIC). A DNS server for Unix machines, the Berkeley Internet Name Domain (BIND) package, was written soon after by a group of graduate students at the University of California at Berkeley under a grant from the US Defense Advanced Research Projects Administration (DARPA). Versions of BIND through 4.8.3 were maintained by the Computer Systems Research Group (CSRG) at UC Berkeley. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the initial BIND project team. After that, additional work on the software package was done by Ralph Campbell. Kevin Dunlap, a Digital Equipment Corporation employee on loan to the CSRG, worked on BIND for 2 years, from 1985 to 1987. Many other people also contributed to BIND development during that time: Doug Kingston, Craig Partridge, Smoot Carl-Mitchell, Mike Muuss, Jim Bloom and Mike Schwartz. BIND maintenance was subsequently handled by Mike Karels and O. Kure.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000946">
</A>
</A>
BIND versions 4.9 and 4.9.1 were released by Digital Equipment Corporation (now Compaq Computer Corporation). Paul Vixie, then a DEC employee, became BIND's primary caretaker. Paul was assisted by Phil Almquist, Robert Elz, Alan Barrett, Paul Albitz, Bryan Beecher, Andrew Partan, Andy Cherenson, Tom Limoncelli, Berthold Paffrath, Fuat Baran, Anant Kumar, Art Harkin, Win Treese, Don Lewis, Christophe Wolfhugel, and others.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000947">
</A>
</A>
BIND Version 4.9.2 was sponsored by Vixie Enterprises. Paul Vixie became BIND's principal architect/programmer.</P>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000948">
</A>
</A>
BIND versions from 4.9.3 onward have been developed and maintained by the Internet Software Consortium with support being provided by ISC's sponsors. As co-architects/programmers, Bob Halley and Paul Vixie released the first production-ready version of BIND version 8 in May 1997.</P>
<P CLASS="2LevelContinued1">
<A NAME="pgfId=1000986">
</A>
<EM CLASS="CharFmt">
BIND development work is made possible today by the sponsorship of several corporations, and by the tireless work efforts of numerous individuals.</EM>
</A>
BIND 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>
<H3 CLASS="AppendixLevel1">
<A NAME="pgfId=1001064">
</A>
</A>
<A NAME="13688">
</A>
</A>
Appendix B. Historical DNS Information</H3>
<DIV>
<H4 CLASS="AppendixLevel2">
<A NAME="pgfId=1001089">
</A>
</A>
Classes of resource records</H4>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=1001093">
</A>
</A>
HS = hesiod</H6>
</DIV>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=1001097">
</A>
</A>
CH = chaos</H6>
</DIV>
</DIV>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
<DIV>
<H3 CLASS="AppendixLevel1">
<A NAME="pgfId=1000908">
</A>
</A>
Appendix C. Bibliography (and Suggested Reading)</H3>
<DIV>
<H4 CLASS="AppendixLevel2">
<A NAME="pgfId=999193">
</A>
</A>
Request for Comments (RFCs)</H4>
<P CLASS="2LevelContinued">
<A NAME="pgfId=999780">
</A>
</A>
Specification documents for the Internet protocol suite, including the DNS, are published as part of the Request for Comments (RFCs) series of technical notes. The standards themselvers are defined by the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG). RFCs can be obtained online via FTP at <BR>
<EM CLASS="URL">
ftp://www.isi.edu/in-notes/RFCxxx.txt</EM>
(where <EM CLASS="URL">
xxx</EM>
is the number of the RFC). RFCs are also available via the Web at <EM CLASS="URL">
http://www.ietf.org/rfc/</EM>
<a href="http://www.ietf.org/rfc/"> http://www.ietf.org/rfc/</A></EM>
.</P>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999212">
</A>
</A>
Standards</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999776">
</A>
</A>
RFC974. Partridge, C. <EM CLASS="doc-title">
Mail Routing and the Domain System</EM>
. January 1986. (Standard </P>
<P CLASS="Bib3">
<A NAME="pgfId=999777">
</A>
</A>
RFC1034. Mockapetris, P.V. <EM CLASS="doc-title">
Domain Names - Concepts and Facilities</EM>
. P.V. November 1987.</P>
<P CLASS="Bib3">
<A NAME="pgfId=1000013">
</A>
</A>
RFC1035. Mockapetris, P. V. <EM CLASS="doc-title">
Domain Names - Implementation and Specification</EM>
. November 1987.</P>
@@ -124,35 +124,35 @@ Domain Names - Implementation and Specification</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999218">
</A>
</A>
Proposed Standards</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999220">
</A>
</A>
RFC2181. Elz, R., R. Bush. <EM CLASS="doc-title">
Clarifications to the DNS Specification</EM>
. July 1997.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999221">
</A>
</A>
RFC2308. Andrews, M. <EM CLASS="doc-title">
Negative Caching of DNS Queries</EM>
. March 1998.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999222">
</A>
</A>
RFC1995. Ohta, M. <EM CLASS="doc-title">
Incremental Zone Transfer in DNS</EM>
. August 1996.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999223">
</A>
</A>
RFC1996. Vixie, P. <EM CLASS="doc-title">
A Mechanism for Prompt Notification of Zone Changes</EM>
. August 1996.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999747">
</A>
</A>
RFC2136. Vixie, P., S. Thomson, Y. Rekhter, J. Bound. <EM CLASS="doc-title">
Dynamic Updates in the Domain Name System</EM>
. April 1997.</P>
@@ -160,11 +160,11 @@ Dynamic Updates in the Domain Name System</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999227">
</A>
</A>
Proposed Standards Still Under Development</H6>
<P CLASS="3LevelContinued">
<A NAME="pgfId=999436">
</A>
</A>
<EM CLASS="doc-title1">
Note:</EM>
the following list of RFCs are undergoing major revision by the IETF. (See the Internet Drafts section below
@@ -172,19 +172,19 @@ for current versions.)
</P>
<P CLASS="Bib3">
<A NAME="pgfId=999230">
</A>
</A>
RFC1886. Thomson, S., C. Huitema. <EM CLASS="doc-title">
DNS Extensions to support IP version 6</EM>
. S. December 1995.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999231">
</A>
</A>
RFC2065. Eastlake, 3rd, D., C. Kaufman. <EM CLASS="doc-title">
Domain Name System Security Extensions</EM>
. January 1997.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999232">
</A>
</A>
RFC2137. Eastlake, 3rd, D. <EM CLASS="doc-title">
Secure Domain Name System Dynamic Update</EM>
. April 1997.</P>
@@ -192,23 +192,23 @@ Secure Domain Name System Dynamic Update</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999235">
</A>
</A>
Other Important RFCs About DNS Implementation</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999237">
</A>
</A>
RFC1535. Gavron, E. <EM CLASS="doc-title">
A Security Problem and Proposed Correction With Widely Deployed DNS Software.</EM>
October 1993.</P>
<P CLASS="Bib3">
<A NAME="pgfId=1000173">
</A>
</A>
RFC1536. Kumar, A., J. Postel, C. Neuman, P. Danzig, S. Miller. <EM CLASS="doc-title">
Common DNS Implementation Errors and Suggested Fixes</EM>
. October 1993.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999239">
</A>
</A>
RFC1982. Elz, R., R. Bush. <EM CLASS="doc-title">
Serial Number Arithmetic</EM>
. August 1996.</P>
@@ -216,41 +216,41 @@ Serial Number Arithmetic</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999242">
</A>
</A>
Resource Record Types</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999244">
</A>
</A>
RFC1183. Everhart, C.F., L. A. Mamakos, R. Ullmann, P. Mockapetris. <EM CLASS="doc-title">
New DNS RR Definitions</EM>
. October 1990.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999249">
</A>
</A>
RFC1706. Manning, B., R. Colella. <EM CLASS="doc-title">
DNS NSAP Resource Records</EM>
. October 1994.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999253">
</A>
</A>
RFC2168. Danie1,R., M. Mealling. <EM CLASS="doc-title">
Resolution of Uniform Resource Identifiers using the Domain Name System. June 1997.</EM>
</P>
<P CLASS="Bib3">
<A NAME="pgfId=999254">
</A>
</A>
RFC1876. Davis, C., P. Vixie, T. Goodwin, I. Dickinson. <EM CLASS="doc-title">
A Means for Expressing Location Information in the Domain Name System</EM>
. January 1996.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999255">
</A>
</A>
RFC2052. Gulbrandsen,A., P. Vixie. <EM CLASS="doc-title">
A DNS RR for Specifying the Location of Services.</EM>
October 1996.</P>
<P CLASS="Bib31">
<A NAME="pgfId=1000261">
</A>
</A>
<EM CLASS="CharFmt">
RFC2163. Allocchio, A. U</EM>
<EM CLASS="doc-title">
@@ -262,7 +262,7 @@ January 1998.</EM>
</P>
<P CLASS="Bib3">
<A NAME="pgfId=1000251">
</A>
</A>
RFC2230. Atkinson, R. <EM CLASS="doc-title">
Key Exchange Delegation Record for the DNS</EM>
. October 1997.</P>
@@ -270,29 +270,29 @@ Key Exchange Delegation Record for the DNS</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999260">
</A>
</A>
DNS and the Internet</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999262">
</A>
</A>
RFC1101. Mockapetris, P. V. <EM CLASS="doc-title">
Dns Encoding of Network Names and Other Types</EM>
. April 1989.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999263">
</A>
</A>
RFC1123. Braden, R. <EM CLASS="doc-title">
Requirements for Internet Hosts - Application and Support</EM>
. October 1989.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999264">
</A>
</A>
RFC1591. Postel, J. D<EM CLASS="doc-title">
omain Name System Structure and Delegation</EM>
. March 1994.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999265">
</A>
</A>
RFC2317. Eidnes, H., G. de Groot, P. Vixie. <EM CLASS="doc-title">
Classless IN-ADDR.ARPA Delegation</EM>
. March 1998.</P>
@@ -300,29 +300,29 @@ Classless IN-ADDR.ARPA Delegation</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999274">
</A>
</A>
DNS Operations</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999276">
</A>
</A>
RFC1537. Beertema, P. <EM CLASS="doc-title">
Common DNS Data File Configuration Errors</EM>
. October 1993.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999277">
</A>
</A>
RFC1912. Barr, D. <EM CLASS="doc-title">
Common DNS Operational and Configuration Errors</EM>
. February 1996.</P>
<P CLASS="Bib3">
<A NAME="pgfId=1000360">
</A>
</A>
RFC2182. Elz, R. R. Bush, S. Bradner, M. Patton. <EM CLASS="doc-title">
Selection and Operation of Secondary DNS Servers</EM>
. July 1997.</P>
<P CLASS="Bib3">
<A NAME="pgfId=1000361">
</A>
</A>
RFC2219. Hamilton, M., R. Wright. <EM CLASS="doc-title">
Use of DNS Aliases for Network Services.</EM>
October 1997.</P>
@@ -330,47 +330,47 @@ Use of DNS Aliases for Network Services.</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999282">
</A>
</A>
Other DNS-related RFCs</H6>
<P CLASS="3LevelContinued1">
<A NAME="pgfId=999409">
</A>
</A>
<EM CLASS="doc-title">
Note:</EM>
the following list of RFCs, although DNS-related, are not concerned with implementing software.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999284">
</A>
</A>
RFC1464. Rosenbaum, R. <EM CLASS="doc-title">
Using the Domain Name System To Store Arbitrary String Attributes</EM>
. May 1993.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999285">
</A>
</A>
RFC1713. Romao, A. <EM CLASS="doc-title">
Tools for DNS Debugging</EM>
. November 1994.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999286">
</A>
</A>
RFC1794. Brisco, T. <EM CLASS="doc-title">
DNS Support for Load Balancing</EM>
. April 1995.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999287">
</A>
</A>
RFC2240. Vaughan, O. <EM CLASS="doc-title">
A Legal Basis for Domain Name Allocation</EM>
. November1997.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999288">
</A>
</A>
RFC2345. Klensin, J., T. Wolf, G. Oglesby. <EM CLASS="doc-title">
Domain Names and Company Name Retrieval</EM>
. May 1998.</P>
<P CLASS="Bib3">
<A NAME="pgfId=999289">
</A>
</A>
RFC2352. Vaughan, O. <EM CLASS="doc-title">
A Convention For Using Legal Names as Domain Names</EM>
. May 1998.</P>
@@ -378,11 +378,11 @@ A Convention For Using Legal Names as Domain Names</EM>
<DIV>
<H6 CLASS="AppendixLevel3">
<A NAME="pgfId=999292">
</A>
</A>
Obsolete and Unimplemented Experimental RRs</H6>
<P CLASS="Bib3">
<A NAME="pgfId=999294">
</A>
</A>
RFC1712. Farrell, C., M. Schulze, S. Pleitner, D. Baldoni. <EM CLASS="doc-title">
DNS Encoding of Geographical Location</EM>
. November 1994.</P>
@@ -391,36 +391,25 @@ DNS Encoding of Geographical Location</EM>
<DIV>
<H6 CLASS="AppendixLevel2">
<A NAME="pgfId=999195">
</A>
</A>
<A NAME="">
</A>
</A>
Internet Drafts</H6>
<P CLASS="2LevelContinued">
<A NAME="pgfId=1000609">
</A>
</A>
Internet Drafts (IDs) are rough-draft working documents of the Internet Engineering Task Force. They are, in essence, RFCs in the preliminary stages of development. Implementors are cautioned not to regard IDs as archival, and they should not be quoted or cited in any formal documents unless accompanied by the disclaimer that they are &quot;works in progress.&quot; IDs have a lifespan of six months after which they are deleted unless updated by their authors.</P>
<P CLASS="2LevelContinued1">
<A NAME="pgfId=1000433">
</A>
<EM CLASS="CharFmt">
IDs can be obtained via </EM>
<CODE CLASS="Program-Process">
FTP</CODE>
<EM CLASS="CharFmt">
from<BR>
</EM>
<EM CLASS="URL">
ftp://www.isi.edu/internet-drafts/</EM>
<EM CLASS="CharFmt">
or from</EM>
<EM CLASS="URL">
http://www.ietf.org/1id-abstracts.html</EM>
<EM CLASS="CharFmt">
.</EM>
</A>
IDs can be obtained via FTP from
<a href="ftp://www.isi.edu/internet-drafts/">ftp://www.isi.edu/internet-drafts/</A>
or from
<a href="http://www.ietf.org/1id-abstracts.html">http://www.ietf.org/1id-abstracts.html</A>.
</P>
<P CLASS="2LevelContinued2">
<A NAME="pgfId=1000877">
</A>
</A>
<EM CLASS="doc-title">
draft-duerst-dns-i18n-01.txt<BR>
draft-ietf-dhc-dhcp-dns-10.txt<BR>
@@ -459,17 +448,17 @@ draft-skwan-utf8-dns-02.txt</EM>
<DIV>
<H6 CLASS="AppendixLevel2">
<A NAME="pgfId=999464">
</A>
</A>
Electronic Mail Communication</H6>
<P CLASS="Bib2">
<A NAME="pgfId=1001024">
</A>
</A>
Wellington, Brian (bwellington@tislabs.com). <EM CLASS="doc-title">
DNSSEC usage document</EM>
. E-mail to David Conrad (David_Conrad@isc.org). 15 March 1999.</P>
<P CLASS="Bib2">
<A NAME="pgfId=1001025">
</A>
</A>
Wellington, Brian (bwellington@tislabs.com). <EM CLASS="doc-title">
TSIG guide for BIND 8.2+</EM>
. E-mail to private mailing list (private communication). 22 April 1999.</P>
@@ -477,16 +466,16 @@ TSIG guide for BIND 8.2+</EM>
<DIV>
<H6 CLASS="AppendixLevel2">
<A NAME="pgfId=1000764">
</A>
</A>
Other BIND Documents</H6>
<P CLASS="Bib2">
<A NAME="pgfId=999522">
</A>
</A>
Albitz, Paul and Cricket Liu. 1998. <EM CLASS="doc-title">
DNS and BIND</EM>
. Sebastopol, CA: O'Reilly and Associates.</P>
<p>Return to <A href="BV9ARM.HTML">BINDv9 Administrator Reference Manual</A> table of contents.</p>
<p>Return to <A href="BV9ARM.html">BINDv9 Administrator Reference Manual</A> table of contents.</p>
</DIV>
</DIV>
</BODY>

BIN
doc/arm/BV9ARM.PDF
View File

Binary file not shown.

1460
doc/arm/BV9ARM.css Normal file
View File

File diff suppressed because it is too large Load Diff

44
doc/arm/BV9ARM.HTML → doc/arm/BV9ARM.html
View File

@@ -13,48 +13,48 @@
<DIV ALIGN="left">
<H2>BIND version 9<BR>Administrator Reference Manual</H2>
<H2>DRAFT
</H2>
<H4>February 1, 2000
</H4>
<br>
March 19, 2000</H2>
</DIV>
<HR ALIGN="center">
<DIV ALIGN="left">
<H4>Warning! this draft document is the property of the Internet Software Consortium (ISC) and contains proprietary ISC information. It is being distributed for review purposes ONLY. The information in this document is subject to change. Do not redistribute!</H4>
<H4>Warning! This DRAFT document is the property of the Internet Software Consortium (ISC) and contains proprietary ISC information. The information in this document is subject to change.</H4>
</DIV>
<HR ALIGN="center">
<OL>
<H3 CLASS="1LevelTOC">
<A HREF="BV9ARM.1.html#pgfId=997350" CLASS="Hypertext">
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.1.html#pgfId=1007883" CLASS="Hypertext">
Section 1. Introduction </A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.2.html#pgfId=997350" CLASS="Hypertext">
Section 2. BIND Resource Requirements</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.3.html#pgfId=997350" CLASS="Hypertext">
Section 3. Nameserver Configuration</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.4.html#pgfId=997350" CLASS="Hypertext">
Section 4. Advanced Concepts</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.5.html#pgfId=997350" CLASS="Hypertext">
Section 5. BINDv9 Configuration Reference</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.6.html#pgfId=997350" CLASS="Hypertext">
Section 6. Security Considerations</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.7.html#pgfId=997350" CLASS="Hypertext">
Section 7. Troubleshooting</A>
</H3>
<H3 CLASS="1LevelTOC">
</H1>
<H1 CLASS="1LevelTOC">
<A HREF="BV9ARM.8.html#pgfId=997350" CLASS="Hypertext">
Appendices</A>
</H3>
</H1>
</OL>
</BODY>
</HTML>