2
0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 13:38:26 +00:00

expanded treatment of stub zones

This commit is contained in:
Andreas Gustafsson 2001-01-16 21:11:32 +00:00
parent 333fe280eb
commit af1e802260

View File

@ -2,7 +2,7 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd">
<!-- File: $Id: Bv9ARM-book.xml,v 1.84 2001/01/15 19:50:53 bwelling Exp $ -->
<!-- File: $Id: Bv9ARM-book.xml,v 1.85 2001/01/16 21:11:32 gson Exp $ -->
<book>
@ -3866,18 +3866,32 @@ behave very slowly if you put 100K files into a single directory.)</para></entry
<entry colname = "2"><para>A stub zone is similar to a slave zone,
except that it replicates only the NS records of a master zone instead
of the entire zone. Stub zones are not a standard part of the DNS;
they are a peculiarity of <acronym>BIND</acronym> 4 and <acronym>BIND</acronym> 8 that relies heavily
on the particular way the zone data is structured in those servers.
<acronym>BIND</acronym> 9 attempts to emulate the <acronym>BIND</acronym> 4/8 stub zone feature for backwards compatibility,
but we do not recommend its use in new configurations.</para><para>In
<acronym>BIND</acronym> 4/8, zone transfers of a parent zone included the NS records
from stub children of that zone. This meant that, in some cases,
users could get away with configuring child stubs only in the master
server for the parent zone. <acronym>BIND</acronym> 9 never mixes together zone data
from different zones in this way. Therefore, if a <acronym>BIND</acronym> 9 master
serving a parent zone has child stub zones configured, all the slave
servers for the parent zone also need to have the same child stub
zones configured.</para></entry>
they are a feature specific to the <acronym>BIND</acronym> implementation.
</para>
<para>Stub zones can be used to eliminate the need for glue NS record
in a parent zone at the expense of maintaining a stub zone entry and
a set of name server addresses in <filename>named.conf</filename>.
This usage is not recommended for new configurations, and BIND 9
supports it only in a limited way.
In <acronym>BIND</acronym> 4/8, zone transfers of a parent zone
included the NS records from stub children of that zone. This meant
that, in some cases, users could get away with configuring child stubs
only in the master server for the parent zone. <acronym>BIND</acronym>
9 never mixes together zone data from different zones in this
way. Therefore, if a <acronym>BIND</acronym> 9 master serving a parent
zone has child stub zones configured, all the slave servers for the
parent zone also need to have the same child stub zones
configured.</para>
<para>Stub zones can also be used as a way of forcing the resolution
of a given domain to use a particular set of authoritative servers.
For example, the caching name servers on a private network using
RFC2157 addressing may be configured with stub zones for
<literal>10.in-addr.arpa</literal>
to use a set of internal name servers as the authoritative
servers for that domain.</para>
</entry>
</row>
<row rowsep = "0">
<entry colname = "1"><para><varname>forward</varname></para></entry>