Annotation of src/external/mpl/bind/dist/doc/arm/Bv9ARM.ch01.html, Revision 1.1.1.4.2.3
1.1.1.4.2.2 christos 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2: <!--
3: - Copyright (C) 2000-2019 Internet Systems Consortium, Inc. ("ISC")
4: -
5: - This Source Code Form is subject to the terms of the Mozilla Public
6: - License, v. 2.0. If a copy of the MPL was not distributed with this
7: - file, You can obtain one at http://mozilla.org/MPL/2.0/.
8: -->
9: <html lang="en">
10: <head>
11: <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
12: <title>Chapter 1. Introduction</title>
13: <meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
14: <link rel="home" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
15: <link rel="up" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
16: <link rel="prev" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
17: <link rel="next" href="Bv9ARM.ch02.html" title="Chapter 2. BIND Resource Requirements">
18: </head>
19: <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
20: <div class="navheader">
21: <table width="100%" summary="Navigation header">
22: <tr><th colspan="3" align="center">Chapter 1. Introduction</th></tr>
23: <tr>
24: <td width="20%" align="left">
25: <a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
26: <th width="60%" align="center"> </th>
27: <td width="20%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
28: </td>
29: </tr>
30: </table>
31: <hr>
32: </div>
33: <div class="chapter">
34: <div class="titlepage"><div><div><h1 class="title">
35: <a name="Bv9ARM.ch01"></a>Chapter 1. Introduction</h1></div></div></div>
36: <div class="toc">
37: <p><b>Table of Contents</b></p>
38: <dl class="toc">
39: <dt><span class="section"><a href="Bv9ARM.ch01.html#doc_scope">Scope of Document</a></span></dt>
40: <dt><span class="section"><a href="Bv9ARM.ch01.html#organization">Organization of This Document</a></span></dt>
41: <dt><span class="section"><a href="Bv9ARM.ch01.html#conventions">Conventions Used in This Document</a></span></dt>
42: <dt><span class="section"><a href="Bv9ARM.ch01.html#dns_overview">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
43: <dd><dl>
44: <dt><span class="section"><a href="Bv9ARM.ch01.html#dns_fundamentals">DNS Fundamentals</a></span></dt>
45: <dt><span class="section"><a href="Bv9ARM.ch01.html#domain_names">Domains and Domain Names</a></span></dt>
46: <dt><span class="section"><a href="Bv9ARM.ch01.html#zones">Zones</a></span></dt>
47: <dt><span class="section"><a href="Bv9ARM.ch01.html#auth_servers">Authoritative Name Servers</a></span></dt>
48: <dt><span class="section"><a href="Bv9ARM.ch01.html#cache_servers">Caching Name Servers</a></span></dt>
49: <dt><span class="section"><a href="Bv9ARM.ch01.html#multi_role">Name Servers in Multiple Roles</a></span></dt>
50: </dl></dd>
51: </dl>
52: </div>
53:
54: <p>
55: The Internet Domain Name System (<acronym class="acronym">DNS</acronym>)
56: consists of the syntax
57: to specify the names of entities in the Internet in a hierarchical
58: manner, the rules used for delegating authority over names, and the
59: system implementation that actually maps names to Internet
60: addresses. <acronym class="acronym">DNS</acronym> data is maintained in a
61: group of distributed
62: hierarchical databases.
63: </p>
64:
65: <div class="section">
66: <div class="titlepage"><div><div><h2 class="title" style="clear: both">
67: <a name="doc_scope"></a>Scope of Document</h2></div></div></div>
68:
69: <p>
70: The Berkeley Internet Name Domain
71: (<acronym class="acronym">BIND</acronym>) implements a
72: domain name server for a number of operating systems. This
73: document provides basic information about the installation and
74: care of the Internet Systems Consortium (<acronym class="acronym">ISC</acronym>)
75: <acronym class="acronym">BIND</acronym> version 9 software package for
76: system administrators.
77: </p>
78: <p>This version of the manual corresponds to BIND version 9.14.</p>
79: </div>
80:
81: <div class="section">
82: <div class="titlepage"><div><div><h2 class="title" style="clear: both">
83: <a name="organization"></a>Organization of This Document</h2></div></div></div>
84:
85: <p>
86: In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces
87: the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span>
88: describes resource requirements for running <acronym class="acronym">BIND</acronym> in various
89: environments. Information in <span class="emphasis"><em>Chapter 3</em></span> is
90: <span class="emphasis"><em>task-oriented</em></span> in its presentation and is
91: organized functionally, to aid in the process of installing the
92: <acronym class="acronym">BIND</acronym> 9 software. The task-oriented
93: section is followed by
94: <span class="emphasis"><em>Chapter 4</em></span>, which contains more advanced
95: concepts that the system administrator may need for implementing
96: certain options. The contents of <span class="emphasis"><em>Chapter 5</em></span> are
97: organized as in a reference manual to aid in the ongoing
98: maintenance of the software. <span class="emphasis"><em>Chapter 6</em></span> addresses
99: security considerations, and
100: <span class="emphasis"><em>Chapter 7</em></span> contains troubleshooting help. The
101: main body of the document is followed by several
102: <span class="emphasis"><em>appendices</em></span> which contain useful reference
103: information, such as a <span class="emphasis"><em>bibliography</em></span> and
104: historic information related to <acronym class="acronym">BIND</acronym>
105: and the Domain Name
106: System.
107: </p>
108: </div>
109: <div class="section">
110: <div class="titlepage"><div><div><h2 class="title" style="clear: both">
111: <a name="conventions"></a>Conventions Used in This Document</h2></div></div></div>
112:
113: <p>
114: In this document, we use the following general typographic
115: conventions:
116: </p>
117:
118: <div class="informaltable">
119: <table border="1">
120: <colgroup>
121: <col width="3.000in" class="1">
122: <col width="2.625in" class="2">
123: </colgroup>
124: <tbody>
125: <tr>
126: <td>
127: <p>
128: <span class="emphasis"><em>To describe:</em></span>
129: </p>
130: </td>
131: <td>
132: <p>
133: <span class="emphasis"><em>We use the style:</em></span>
134: </p>
135: </td>
136: </tr>
137: <tr>
138: <td>
139: <p>
140: a pathname, filename, URL, hostname,
141: mailing list name, or new term or concept
142: </p>
143: </td>
144: <td>
145: <p>
146: <code class="filename">Fixed width</code>
147: </p>
148: </td>
149: </tr>
150: <tr>
151: <td>
152: <p>
153: literal user
154: input
155: </p>
156: </td>
157: <td>
158: <p>
159: <strong class="userinput"><code>Fixed Width Bold</code></strong>
160: </p>
161: </td>
162: </tr>
163: <tr>
164: <td>
165: <p>
166: program output
167: </p>
168: </td>
169: <td>
170: <p>
171: <code class="computeroutput">Fixed Width</code>
172: </p>
173: </td>
174: </tr>
175: </tbody>
176: </table>
177: </div>
178:
179: <p>
180: The following conventions are used in descriptions of the
181: <acronym class="acronym">BIND</acronym> configuration file:</p>
182: <div class="informaltable">
183: <table border="1">
184: <colgroup>
185: <col width="3.000in" class="1">
186: <col width="2.625in" class="2">
187: </colgroup>
188: <tbody>
189: <tr>
190: <td>
191: <p>
192: <span class="emphasis"><em>To describe:</em></span>
193: </p>
194: </td>
195: <td>
196: <p>
197: <span class="emphasis"><em>We use the style:</em></span>
198: </p>
199: </td>
200: </tr>
201: <tr>
202: <td>
203: <p>
204: keywords
205: </p>
206: </td>
207: <td>
208: <p>
209: <code class="literal">Fixed Width</code>
210: </p>
211: </td>
212: </tr>
213: <tr>
214: <td>
215: <p>
216: variables
217: </p>
218: </td>
219: <td>
220: <p>
221: <code class="varname">Fixed Width</code>
222: </p>
223: </td>
224: </tr>
225: <tr>
226: <td>
227: <p>
228: Optional input
229: </p>
230: </td>
231: <td>
232: <p>
233: [<span class="optional">Text is enclosed in square brackets</span>]
234: </p>
235: </td>
236: </tr>
237: </tbody>
238: </table>
239: </div>
240: <p>
241: </p>
242: </div>
243: <div class="section">
244: <div class="titlepage"><div><div><h2 class="title" style="clear: both">
245: <a name="dns_overview"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
246:
247: <p>
248: The purpose of this document is to explain the installation
249: and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
250: Name Domain) software package, and we
251: begin by reviewing the fundamentals of the Domain Name System
252: (<acronym class="acronym">DNS</acronym>) as they relate to <acronym class="acronym">BIND</acronym>.
253: </p>
254:
255: <div class="section">
256: <div class="titlepage"><div><div><h3 class="title">
257: <a name="dns_fundamentals"></a>DNS Fundamentals</h3></div></div></div>
258:
259: <p>
260: The Domain Name System (DNS) is a hierarchical, distributed
261: database. It stores information for mapping Internet host names to
262: IP
263: addresses and vice versa, mail routing information, and other data
264: used by Internet applications.
265: </p>
266:
267: <p>
268: Clients look up information in the DNS by calling a
269: <span class="emphasis"><em>resolver</em></span> library, which sends queries to one or
270: more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
271: The <acronym class="acronym">BIND</acronym> 9 software distribution
272: contains a name server, <span class="command"><strong>named</strong></span>, and a set
273: of associated tools.
274: </p>
275:
276: </div>
277: <div class="section">
278: <div class="titlepage"><div><div><h3 class="title">
279: <a name="domain_names"></a>Domains and Domain Names</h3></div></div></div>
280:
281: <p>
282: The data stored in the DNS is identified by <span class="emphasis"><em>domain names</em></span> that are organized as a tree according to
283: organizational or administrative boundaries. Each node of the tree,
284: called a <span class="emphasis"><em>domain</em></span>, is given a label. The domain
285: name of the
286: node is the concatenation of all the labels on the path from the
287: node to the <span class="emphasis"><em>root</em></span> node. This is represented
288: in written form as a string of labels listed from right to left and
289: separated by dots. A label need only be unique within its parent
290: domain.
291: </p>
292:
293: <p>
294: For example, a domain name for a host at the
295: company <span class="emphasis"><em>Example, Inc.</em></span> could be
296: <code class="literal">ourhost.example.com</code>,
297: where <code class="literal">com</code> is the
298: top level domain to which
299: <code class="literal">ourhost.example.com</code> belongs,
300: <code class="literal">example</code> is
301: a subdomain of <code class="literal">com</code>, and
302: <code class="literal">ourhost</code> is the
303: name of the host.
304: </p>
305:
306: <p>
307: For administrative purposes, the name space is partitioned into
308: areas called <span class="emphasis"><em>zones</em></span>, each starting at a node and
309: extending down to the leaf nodes or to nodes where other zones
310: start.
311: The data for each zone is stored in a <span class="emphasis"><em>name server</em></span>, which answers queries about the zone using the
312: <span class="emphasis"><em>DNS protocol</em></span>.
313: </p>
314:
315: <p>
316: The data associated with each domain name is stored in the
317: form of <span class="emphasis"><em>resource records</em></span> (<acronym class="acronym">RR</acronym>s).
318: Some of the supported resource record types are described in
319: <a class="xref" href="Bv9ARM.ch05.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>.
320: </p>
321:
322: <p>
323: For more detailed information about the design of the DNS and
324: the DNS protocol, please refer to the standards documents listed in
325: <a class="xref" href="Bv9ARM.ch10.html#rfcs" title="Request for Comments (RFCs)">the section called “Request for Comments (RFCs)”</a>.
326: </p>
327: </div>
328:
329: <div class="section">
330: <div class="titlepage"><div><div><h3 class="title">
331: <a name="zones"></a>Zones</h3></div></div></div>
332:
333: <p>
334: To properly operate a name server, it is important to understand
335: the difference between a <span class="emphasis"><em>zone</em></span>
336: and a <span class="emphasis"><em>domain</em></span>.
337: </p>
338:
339: <p>
340: As stated previously, a zone is a point of delegation in
341: the <acronym class="acronym">DNS</acronym> tree. A zone consists of
342: those contiguous parts of the domain
343: tree for which a name server has complete information and over which
344: it has authority. It contains all domain names from a certain point
345: downward in the domain tree except those which are delegated to
346: other zones. A delegation point is marked by one or more
347: <span class="emphasis"><em>NS records</em></span> in the
348: parent zone, which should be matched by equivalent NS records at
349: the root of the delegated zone.
350: </p>
351:
352: <p>
353: For instance, consider the <code class="literal">example.com</code>
354: domain which includes names
355: such as <code class="literal">host.aaa.example.com</code> and
356: <code class="literal">host.bbb.example.com</code> even though
357: the <code class="literal">example.com</code> zone includes
358: only delegations for the <code class="literal">aaa.example.com</code> and
359: <code class="literal">bbb.example.com</code> zones. A zone can
360: map
361: exactly to a single domain, but could also include only part of a
362: domain, the rest of which could be delegated to other
363: name servers. Every name in the <acronym class="acronym">DNS</acronym>
364: tree is a
365: <span class="emphasis"><em>domain</em></span>, even if it is
366: <span class="emphasis"><em>terminal</em></span>, that is, has no
367: <span class="emphasis"><em>subdomains</em></span>. Every subdomain is a domain and
368: every domain except the root is also a subdomain. The terminology is
369: not intuitive and we suggest that you read RFCs 1033, 1034 and 1035
370: to
371: gain a complete understanding of this difficult and subtle
372: topic.
373: </p>
374:
375: <p>
376: Though <acronym class="acronym">BIND</acronym> is called a "domain name
377: server",
378: it deals primarily in terms of zones. The master and slave
379: declarations in the <code class="filename">named.conf</code> file
380: specify
381: zones, not domains. When you ask some other site if it is willing to
382: be a slave server for your <span class="emphasis"><em>domain</em></span>, you are
383: actually asking for slave service for some collection of zones.
384: </p>
385: </div>
386:
387: <div class="section">
388: <div class="titlepage"><div><div><h3 class="title">
389: <a name="auth_servers"></a>Authoritative Name Servers</h3></div></div></div>
390:
391: <p>
392: Each zone is served by at least
393: one <span class="emphasis"><em>authoritative name server</em></span>,
394: which contains the complete data for the zone.
395: To make the DNS tolerant of server and network failures,
396: most zones have two or more authoritative servers, on
397: different networks.
398: </p>
399:
400: <p>
401: Responses from authoritative servers have the "authoritative
402: answer" (AA) bit set in the response packets. This makes them
403: easy to identify when debugging DNS configurations using tools like
404: <span class="command"><strong>dig</strong></span> (<a class="xref" href="Bv9ARM.ch03.html#diagnostic_tools" title="Diagnostic Tools">the section called “Diagnostic Tools”</a>).
405: </p>
406:
407: <div class="section">
408: <div class="titlepage"><div><div><h4 class="title">
409: <a name="primary_master"></a>The Primary Master</h4></div></div></div>
410:
411: <p>
412: The authoritative server where the master copy of the zone
413: data is maintained is called the
414: <span class="emphasis"><em>primary master</em></span> server, or simply the
415: <span class="emphasis"><em>primary</em></span>. Typically it loads the zone
416: contents from some local file edited by humans or perhaps
417: generated mechanically from some other local file which is
418: edited by humans. This file is called the
419: <span class="emphasis"><em>zone file</em></span> or
420: <span class="emphasis"><em>master file</em></span>.
421: </p>
422:
423: <p>
424: In some cases, however, the master file may not be edited
425: by humans at all, but may instead be the result of
426: <span class="emphasis"><em>dynamic update</em></span> operations.
427: </p>
428: </div>
429:
430: <div class="section">
431: <div class="titlepage"><div><div><h4 class="title">
432: <a name="slave_server"></a>Slave Servers</h4></div></div></div>
433:
434: <p>
435: The other authoritative servers, the <span class="emphasis"><em>slave</em></span>
436: servers (also known as <span class="emphasis"><em>secondary</em></span> servers)
437: load the zone contents from another server using a replication
438: process known as a <span class="emphasis"><em>zone transfer</em></span>.
439: Typically the data are transferred directly from the primary
440: master, but it is also possible to transfer it from another
441: slave. In other words, a slave server may itself act as a
442: master to a subordinate slave server.
443: </p>
444: <p>
445: Periodically, the slave server must send a refresh query to
446: determine whether the zone contents have been updated. This
447: is done by sending a query for the zone's SOA record and
448: checking whether the SERIAL field has been updated; if so,
449: a new transfer request is initiated. The timing of these
450: refresh queries is controlled by the SOA REFRESH and RETRY
451: fields, but can be overrridden with the
452: <span class="command"><strong>max-refresh-time</strong></span>,
453: <span class="command"><strong>min-refresh-time</strong></span>,
454: <span class="command"><strong>max-retry-time</strong></span>, and
455: <span class="command"><strong>min-retry-time</strong></span> options.
456: </p>
457: <p>
458: If the zone data cannot be updated within the time specified
459: by the SOA EXPIRE option (up to a hard-coded maximum of
460: 24 weeks) then the slave zone expires and will no longer
461: respond to queries.
462: </p>
463: </div>
464:
465: <div class="section">
466: <div class="titlepage"><div><div><h4 class="title">
467: <a name="stealth_server"></a>Stealth Servers</h4></div></div></div>
468:
469: <p>
470: Usually all of the zone's authoritative servers are listed in
471: NS records in the parent zone. These NS records constitute
472: a <span class="emphasis"><em>delegation</em></span> of the zone from the parent.
473: The authoritative servers are also listed in the zone file itself,
474: at the <span class="emphasis"><em>top level</em></span> or <span class="emphasis"><em>apex</em></span>
475: of the zone. You can list servers in the zone's top-level NS
476: records that are not in the parent's NS delegation, but you cannot
477: list servers in the parent's delegation that are not present at
478: the zone's top level.
479: </p>
480:
481: <p>
482: A <span class="emphasis"><em>stealth server</em></span> is a server that is
483: authoritative for a zone but is not listed in that zone's NS
484: records. Stealth servers can be used for keeping a local copy of
485: a
486: zone to speed up access to the zone's records or to make sure that
487: the
488: zone is available even if all the "official" servers for the zone
489: are
490: inaccessible.
491: </p>
492:
493: <p>
494: A configuration where the primary master server itself is a
495: stealth server is often referred to as a "hidden primary"
496: configuration. One use for this configuration is when the primary
497: master
498: is behind a firewall and therefore unable to communicate directly
499: with the outside world.
500: </p>
501:
502: </div>
503:
504: </div>
505: <div class="section">
506: <div class="titlepage"><div><div><h3 class="title">
507: <a name="cache_servers"></a>Caching Name Servers</h3></div></div></div>
508:
509:
510:
511: <p>
512: The resolver libraries provided by most operating systems are
513: <span class="emphasis"><em>stub resolvers</em></span>, meaning that they are not
514: capable of
515: performing the full DNS resolution process by themselves by talking
516: directly to the authoritative servers. Instead, they rely on a
517: local
518: name server to perform the resolution on their behalf. Such a
519: server
520: is called a <span class="emphasis"><em>recursive</em></span> name server; it performs
521: <span class="emphasis"><em>recursive lookups</em></span> for local clients.
522: </p>
523:
524: <p>
525: To improve performance, recursive servers cache the results of
526: the lookups they perform. Since the processes of recursion and
527: caching are intimately connected, the terms
528: <span class="emphasis"><em>recursive server</em></span> and
529: <span class="emphasis"><em>caching server</em></span> are often used synonymously.
530: </p>
531:
532: <p>
533: The length of time for which a record may be retained in
534: the cache of a caching name server is controlled by the
535: Time To Live (TTL) field associated with each resource record.
536: </p>
537:
538: <div class="section">
539: <div class="titlepage"><div><div><h4 class="title">
540: <a name="forwarder"></a>Forwarding</h4></div></div></div>
541:
542: <p>
543: Even a caching name server does not necessarily perform
544: the complete recursive lookup itself. Instead, it can
545: <span class="emphasis"><em>forward</em></span> some or all of the queries
546: that it cannot satisfy from its cache to another caching name
547: server,
548: commonly referred to as a <span class="emphasis"><em>forwarder</em></span>.
549: </p>
550:
551: <p>
552: There may be one or more forwarders,
553: and they are queried in turn until the list is exhausted or an
554: answer
555: is found. Forwarders are typically used when you do not
556: wish all the servers at a given site to interact directly with the
557: rest of
558: the Internet servers. A typical scenario would involve a number
559: of internal <acronym class="acronym">DNS</acronym> servers and an
560: Internet firewall. Servers unable
561: to pass packets through the firewall would forward to the server
562: that can do it, and that server would query the Internet <acronym class="acronym">DNS</acronym> servers
563: on the internal server's behalf.
564: </p>
565: </div>
566:
567: </div>
568:
569: <div class="section">
570: <div class="titlepage"><div><div><h3 class="title">
571: <a name="multi_role"></a>Name Servers in Multiple Roles</h3></div></div></div>
572:
573: <p>
574: The <acronym class="acronym">BIND</acronym> name server can
575: simultaneously act as
576: a master for some zones, a slave for other zones, and as a caching
577: (recursive) server for a set of local clients.
578: </p>
579:
580: <p>
581: However, since the functions of authoritative name service
582: and caching/recursive name service are logically separate, it is
583: often advantageous to run them on separate server machines.
584:
585: A server that only provides authoritative name service
586: (an <span class="emphasis"><em>authoritative-only</em></span> server) can run with
587: recursion disabled, improving reliability and security.
588:
589: A server that is not authoritative for any zones and only provides
590: recursive service to local
591: clients (a <span class="emphasis"><em>caching-only</em></span> server)
592: does not need to be reachable from the Internet at large and can
593: be placed inside a firewall.
594: </p>
595:
596: </div>
597: </div>
598:
599: </div>
600: <div class="navfooter">
601: <hr>
602: <table width="100%" summary="Navigation footer">
603: <tr>
604: <td width="40%" align="left">
605: <a accesskey="p" href="Bv9ARM.html">Prev</a> </td>
606: <td width="20%" align="center"> </td>
607: <td width="40%" align="right"> <a accesskey="n" href="Bv9ARM.ch02.html">Next</a>
608: </td>
609: </tr>
610: <tr>
611: <td width="40%" align="left" valign="top">BIND 9 Administrator Reference Manual </td>
612: <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
613: <td width="40%" align="right" valign="top"> Chapter 2. <acronym class="acronym">BIND</acronym> Resource Requirements</td>
614: </tr>
615: </table>
616: </div>
1.1.1.4.2.3! martin 617: <p xmlns:db="http://docbook.org/ns/docbook" style="text-align: center;">BIND 9.14.8 (Stable Release)</p>
1.1.1.4.2.2 christos 618: </body>
619: </html>
CVSweb <webmaster@jp.NetBSD.org>
![[BACK]](/icons/back.gif){kind=icon}
Return to Bv9ARM.ch01.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / external / mpl / bind / dist / doc / arm