The data associated with each domain name is stored in the
form of <spanclass="emphasis"><em>resource records</em></span> (<acronymclass="acronym">RR</acronym>s).
Some of the supported resource record types are described in
<aclass="xref"href="Bv9ARM.ch06.html#types_of_resource_records_and_when_to_use_them"title="Types of Resource Records and When to Use Them">the section called “Types of Resource Records and When to Use Them”</a>.
</p>
<p>
For more detailed information about the design of the DNS and
the DNS protocol, please refer to the standards documents listed in
<aclass="xref"href="Bv9ARM.ch11.html#rfcs"title="Request for Comments (RFCs)">the section called “Request for Comments (RFCs)”</a>.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h3class="title">
<aname="zones"></a>Zones</h3></div></div></div>
<p>
To properly operate a name server, it is important to understand
the difference between a <spanclass="emphasis"><em>zone</em></span>
and a <spanclass="emphasis"><em>domain</em></span>.
</p>
<p>
As stated previously, a zone is a point of delegation in
the <acronymclass="acronym">DNS</acronym> tree. A zone consists of
those contiguous parts of the domain
tree for which a name server has complete information and over which
it has authority. It contains all domain names from a certain point
downward in the domain tree except those which are delegated to
other zones. A delegation point is marked by one or more
<spanclass="emphasis"><em>NS records</em></span> in the
parent zone, which should be matched by equivalent NS records at
the root of the delegated zone.
</p>
<p>
For instance, consider the <codeclass="literal">example.com</code>
domain which includes names
such as <codeclass="literal">host.aaa.example.com</code> and
<codeclass="literal">host.bbb.example.com</code> even though
the <codeclass="literal">example.com</code> zone includes
only delegations for the <codeclass="literal">aaa.example.com</code> and
<codeclass="literal">bbb.example.com</code> zones. A zone can
map
exactly to a single domain, but could also include only part of a
domain, the rest of which could be delegated to other
name servers. Every name in the <acronymclass="acronym">DNS</acronym>
tree is a
<spanclass="emphasis"><em>domain</em></span>, even if it is
<spanclass="emphasis"><em>terminal</em></span>, that is, has no
<spanclass="emphasis"><em>subdomains</em></span>. Every subdomain is a domain and
every domain except the root is also a subdomain. The terminology is
not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
to
gain a complete understanding of this difficult and subtle
topic.
</p>
<p>
Though <acronymclass="acronym">BIND</acronym> is called a "domain name
server",
it deals primarily in terms of zones. The master and slave
declarations in the <codeclass="filename">named.conf</code> file
specify
zones, not domains. When you ask some other site if it is willing to
be a slave server for your <spanclass="emphasis"><em>domain</em></span>, you are
actually asking for slave service for some collection of zones.
</p>
</div>
<divclass="section">
<divclass="titlepage"><div><div><h3class="title">
<aname="auth_servers"></a>Authoritative Name Servers</h3></div></div></div>
<p>
Each zone is served by at least
one <spanclass="emphasis"><em>authoritative name server</em></span>,
which contains the complete data for the zone.
To make the DNS tolerant of server and network failures,
most zones have two or more authoritative servers, on
different networks.
</p>
<p>
Responses from authoritative servers have the "authoritative
answer" (AA) bit set in the response packets. This makes them
easy to identify when debugging DNS configurations using tools like
<spanclass="command"><strong>dig</strong></span> (<aclass="xref"href="Bv9ARM.ch03.html#diagnostic_tools"title="Diagnostic Tools">the section called “Diagnostic Tools”</a>).
