xref: /minix3/external/bsd/bind/dist/FAQ.xml (revision 00b67f09dd46474d133c95011a48590a8e8f94c7)
1*00b67f09SDavid van Moolenbroek<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2*00b67f09SDavid van Moolenbroek       "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
3*00b67f09SDavid van Moolenbroek<!--
4*00b67f09SDavid van Moolenbroek - Copyright (C) 2004-2010, 2013, 2014  Internet Systems Consortium, Inc. ("ISC")
5*00b67f09SDavid van Moolenbroek - Copyright (C) 2000-2003  Internet Software Consortium.
6*00b67f09SDavid van Moolenbroek -
7*00b67f09SDavid van Moolenbroek - Permission to use, copy, modify, and/or distribute this software for any
8*00b67f09SDavid van Moolenbroek - purpose with or without fee is hereby granted, provided that the above
9*00b67f09SDavid van Moolenbroek - copyright notice and this permission notice appear in all copies.
10*00b67f09SDavid van Moolenbroek -
11*00b67f09SDavid van Moolenbroek - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
12*00b67f09SDavid van Moolenbroek - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
13*00b67f09SDavid van Moolenbroek - AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
14*00b67f09SDavid van Moolenbroek - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
15*00b67f09SDavid van Moolenbroek - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
16*00b67f09SDavid van Moolenbroek - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
17*00b67f09SDavid van Moolenbroek - PERFORMANCE OF THIS SOFTWARE.
18*00b67f09SDavid van Moolenbroek-->
19*00b67f09SDavid van Moolenbroek
20*00b67f09SDavid van Moolenbroek<!-- Id: FAQ.xml,v 1.54 2010/01/19 23:48:55 tbox Exp  -->
21*00b67f09SDavid van Moolenbroek
22*00b67f09SDavid van Moolenbroek<article class="faq">
23*00b67f09SDavid van Moolenbroek  <title>Frequently Asked Questions about BIND 9</title>
24*00b67f09SDavid van Moolenbroek  <articleinfo>
25*00b67f09SDavid van Moolenbroek    <copyright>
26*00b67f09SDavid van Moolenbroek      <year>2004</year>
27*00b67f09SDavid van Moolenbroek      <year>2005</year>
28*00b67f09SDavid van Moolenbroek      <year>2006</year>
29*00b67f09SDavid van Moolenbroek      <year>2007</year>
30*00b67f09SDavid van Moolenbroek      <year>2008</year>
31*00b67f09SDavid van Moolenbroek      <year>2009</year>
32*00b67f09SDavid van Moolenbroek      <year>2010</year>
33*00b67f09SDavid van Moolenbroek      <year>2013</year>
34*00b67f09SDavid van Moolenbroek      <year>2014</year>
35*00b67f09SDavid van Moolenbroek      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
36*00b67f09SDavid van Moolenbroek    </copyright>
37*00b67f09SDavid van Moolenbroek    <copyright>
38*00b67f09SDavid van Moolenbroek      <year>2000</year>
39*00b67f09SDavid van Moolenbroek      <year>2001</year>
40*00b67f09SDavid van Moolenbroek      <year>2002</year>
41*00b67f09SDavid van Moolenbroek      <year>2003</year>
42*00b67f09SDavid van Moolenbroek      <holder>Internet Software Consortium.</holder>
43*00b67f09SDavid van Moolenbroek    </copyright>
44*00b67f09SDavid van Moolenbroek  </articleinfo>
45*00b67f09SDavid van Moolenbroek  <qandaset defaultlabel='qanda'>
46*00b67f09SDavid van Moolenbroek
47*00b67f09SDavid van Moolenbroek    <qandadiv><title>Compilation and Installation Questions</title>
48*00b67f09SDavid van Moolenbroek
49*00b67f09SDavid van Moolenbroek    <qandaentry>
50*00b67f09SDavid van Moolenbroek      <question>
51*00b67f09SDavid van Moolenbroek	<para>
52*00b67f09SDavid van Moolenbroek	  I'm trying to compile BIND 9, and "make" is failing due to
53*00b67f09SDavid van Moolenbroek	  files not being found.  Why?
54*00b67f09SDavid van Moolenbroek	</para>
55*00b67f09SDavid van Moolenbroek      </question>
56*00b67f09SDavid van Moolenbroek      <answer>
57*00b67f09SDavid van Moolenbroek	<para>
58*00b67f09SDavid van Moolenbroek	  Using a parallel or distributed "make" to build BIND 9 is
59*00b67f09SDavid van Moolenbroek	  not supported, and doesn't work.  If you are using one of
60*00b67f09SDavid van Moolenbroek	  these, use normal make or gmake instead.
61*00b67f09SDavid van Moolenbroek	</para>
62*00b67f09SDavid van Moolenbroek      </answer>
63*00b67f09SDavid van Moolenbroek    </qandaentry>
64*00b67f09SDavid van Moolenbroek
65*00b67f09SDavid van Moolenbroek    <qandaentry>
66*00b67f09SDavid van Moolenbroek      <question>
67*00b67f09SDavid van Moolenbroek	<para>
68*00b67f09SDavid van Moolenbroek	  Isn't "make install"  supposed to generate a default named.conf?
69*00b67f09SDavid van Moolenbroek	</para>
70*00b67f09SDavid van Moolenbroek      </question>
71*00b67f09SDavid van Moolenbroek      <answer>
72*00b67f09SDavid van Moolenbroek	<para>
73*00b67f09SDavid van Moolenbroek	  Short Answer: No.
74*00b67f09SDavid van Moolenbroek	</para>
75*00b67f09SDavid van Moolenbroek	<para>
76*00b67f09SDavid van Moolenbroek	  Long Answer: There really isn't a default configuration which fits
77*00b67f09SDavid van Moolenbroek	  any site perfectly.  There are lots of decisions that need to
78*00b67f09SDavid van Moolenbroek	  be made and there is no consensus on what the defaults should be.
79*00b67f09SDavid van Moolenbroek	  For example FreeBSD uses /etc/namedb as the location where the
80*00b67f09SDavid van Moolenbroek	  configuration files for named are stored.  Others use /var/named.
81*00b67f09SDavid van Moolenbroek	</para>
82*00b67f09SDavid van Moolenbroek	<para>
83*00b67f09SDavid van Moolenbroek	  What addresses to listen on?  For a laptop on the move a lot
84*00b67f09SDavid van Moolenbroek	  you may only want to listen on the loop back interfaces.
85*00b67f09SDavid van Moolenbroek	</para>
86*00b67f09SDavid van Moolenbroek	<para>
87*00b67f09SDavid van Moolenbroek	  To whom do you offer recursive service?  Is there a firewall
88*00b67f09SDavid van Moolenbroek	  to consider?  If so, is it stateless or stateful?  Are you
89*00b67f09SDavid van Moolenbroek	  directly on the Internet?  Are you on a private network? Are
90*00b67f09SDavid van Moolenbroek	  you on a NAT'd network? The answers
91*00b67f09SDavid van Moolenbroek	  to all these questions change how you configure even a
92*00b67f09SDavid van Moolenbroek	  caching name server.
93*00b67f09SDavid van Moolenbroek	</para>
94*00b67f09SDavid van Moolenbroek      </answer>
95*00b67f09SDavid van Moolenbroek    </qandaentry>
96*00b67f09SDavid van Moolenbroek
97*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Compilation and Installation Questions -->
98*00b67f09SDavid van Moolenbroek
99*00b67f09SDavid van Moolenbroek    <qandadiv><title>Configuration and Setup Questions</title>
100*00b67f09SDavid van Moolenbroek
101*00b67f09SDavid van Moolenbroek    <qandaentry>
102*00b67f09SDavid van Moolenbroek      <!-- configuration, log -->
103*00b67f09SDavid van Moolenbroek      <question>
104*00b67f09SDavid van Moolenbroek	<para>
105*00b67f09SDavid van Moolenbroek	  Why does named log the warning message <quote>no TTL specified -
106*00b67f09SDavid van Moolenbroek	  using SOA MINTTL instead</quote>?
107*00b67f09SDavid van Moolenbroek	</para>
108*00b67f09SDavid van Moolenbroek      </question>
109*00b67f09SDavid van Moolenbroek      <answer>
110*00b67f09SDavid van Moolenbroek	<para>
111*00b67f09SDavid van Moolenbroek	  Your zone file is illegal according to RFC1035.  It must either
112*00b67f09SDavid van Moolenbroek	  have a line like:
113*00b67f09SDavid van Moolenbroek	</para>
114*00b67f09SDavid van Moolenbroek	<informalexample>
115*00b67f09SDavid van Moolenbroek	  <programlisting>
116*00b67f09SDavid van Moolenbroek$TTL 86400</programlisting>
117*00b67f09SDavid van Moolenbroek	</informalexample>
118*00b67f09SDavid van Moolenbroek	<para>
119*00b67f09SDavid van Moolenbroek	  at the beginning, or the first record in it must have a TTL field,
120*00b67f09SDavid van Moolenbroek	  like the "84600" in this example:
121*00b67f09SDavid van Moolenbroek	</para>
122*00b67f09SDavid van Moolenbroek	<informalexample>
123*00b67f09SDavid van Moolenbroek	  <programlisting>
124*00b67f09SDavid van Moolenbroekexample.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )</programlisting>
125*00b67f09SDavid van Moolenbroek	</informalexample>
126*00b67f09SDavid van Moolenbroek      </answer>
127*00b67f09SDavid van Moolenbroek    </qandaentry>
128*00b67f09SDavid van Moolenbroek
129*00b67f09SDavid van Moolenbroek    <qandaentry>
130*00b67f09SDavid van Moolenbroek      <!-- configuration -->
131*00b67f09SDavid van Moolenbroek      <question>
132*00b67f09SDavid van Moolenbroek	<para>
133*00b67f09SDavid van Moolenbroek	  Why do I get errors like <quote>dns_zone_load: zone foo/IN: loading
134*00b67f09SDavid van Moolenbroek	  master file bar: ran out of space</quote>?
135*00b67f09SDavid van Moolenbroek	</para>
136*00b67f09SDavid van Moolenbroek      </question>
137*00b67f09SDavid van Moolenbroek      <answer>
138*00b67f09SDavid van Moolenbroek	<para>
139*00b67f09SDavid van Moolenbroek	This is often caused by TXT records with missing close
140*00b67f09SDavid van Moolenbroek	quotes.  Check that all TXT records containing quoted strings
141*00b67f09SDavid van Moolenbroek	have both open and close quotes.
142*00b67f09SDavid van Moolenbroek	</para>
143*00b67f09SDavid van Moolenbroek      </answer>
144*00b67f09SDavid van Moolenbroek    </qandaentry>
145*00b67f09SDavid van Moolenbroek
146*00b67f09SDavid van Moolenbroek    <qandaentry>
147*00b67f09SDavid van Moolenbroek      <!-- security -->
148*00b67f09SDavid van Moolenbroek      <question>
149*00b67f09SDavid van Moolenbroek	<para>
150*00b67f09SDavid van Moolenbroek	  How do I restrict people from looking up the server version?
151*00b67f09SDavid van Moolenbroek	</para>
152*00b67f09SDavid van Moolenbroek      </question>
153*00b67f09SDavid van Moolenbroek      <answer>
154*00b67f09SDavid van Moolenbroek	<para>
155*00b67f09SDavid van Moolenbroek	  Put a "version" option containing something other than the
156*00b67f09SDavid van Moolenbroek	  real version in the "options" section of named.conf.  Note
157*00b67f09SDavid van Moolenbroek	  doing this will not prevent attacks and may impede people
158*00b67f09SDavid van Moolenbroek	  trying to diagnose problems with your server.  Also it is
159*00b67f09SDavid van Moolenbroek	  possible to "fingerprint" nameservers to determine their
160*00b67f09SDavid van Moolenbroek	  version.
161*00b67f09SDavid van Moolenbroek	</para>
162*00b67f09SDavid van Moolenbroek      </answer>
163*00b67f09SDavid van Moolenbroek    </qandaentry>
164*00b67f09SDavid van Moolenbroek
165*00b67f09SDavid van Moolenbroek    <qandaentry>
166*00b67f09SDavid van Moolenbroek      <!-- security -->
167*00b67f09SDavid van Moolenbroek      <question>
168*00b67f09SDavid van Moolenbroek	<para>
169*00b67f09SDavid van Moolenbroek	  How do I restrict only remote users from looking up the
170*00b67f09SDavid van Moolenbroek	  server version?
171*00b67f09SDavid van Moolenbroek	</para>
172*00b67f09SDavid van Moolenbroek      </question>
173*00b67f09SDavid van Moolenbroek      <answer>
174*00b67f09SDavid van Moolenbroek	<para>
175*00b67f09SDavid van Moolenbroek	  The following view statement will intercept lookups as the
176*00b67f09SDavid van Moolenbroek	  internal view that holds the version information will be
177*00b67f09SDavid van Moolenbroek	  matched last.  The caveats of the previous answer still
178*00b67f09SDavid van Moolenbroek	  apply, of course.
179*00b67f09SDavid van Moolenbroek	</para>
180*00b67f09SDavid van Moolenbroek	<informalexample>
181*00b67f09SDavid van Moolenbroek	  <programlisting>
182*00b67f09SDavid van Moolenbroekview "chaos" chaos {
183*00b67f09SDavid van Moolenbroek	match-clients { &lt;those to be refused&gt;; };
184*00b67f09SDavid van Moolenbroek	allow-query { none; };
185*00b67f09SDavid van Moolenbroek	zone "." {
186*00b67f09SDavid van Moolenbroek		type hint;
187*00b67f09SDavid van Moolenbroek		file "/dev/null";  // or any empty file
188*00b67f09SDavid van Moolenbroek	};
189*00b67f09SDavid van Moolenbroek};</programlisting>
190*00b67f09SDavid van Moolenbroek	</informalexample>
191*00b67f09SDavid van Moolenbroek      </answer>
192*00b67f09SDavid van Moolenbroek    </qandaentry>
193*00b67f09SDavid van Moolenbroek
194*00b67f09SDavid van Moolenbroek    <qandaentry>
195*00b67f09SDavid van Moolenbroek      <!-- configuration -->
196*00b67f09SDavid van Moolenbroek      <question>
197*00b67f09SDavid van Moolenbroek	<para>
198*00b67f09SDavid van Moolenbroek	  What do <quote>no source of entropy found</quote> or <quote>could not
199*00b67f09SDavid van Moolenbroek	  open entropy source foo</quote> mean?
200*00b67f09SDavid van Moolenbroek	</para>
201*00b67f09SDavid van Moolenbroek      </question>
202*00b67f09SDavid van Moolenbroek      <answer>
203*00b67f09SDavid van Moolenbroek	<para>
204*00b67f09SDavid van Moolenbroek	  The server requires a source of entropy to perform certain
205*00b67f09SDavid van Moolenbroek	  operations, mostly DNSSEC related.  These messages indicate
206*00b67f09SDavid van Moolenbroek	  that you have no source of entropy.  On systems with
207*00b67f09SDavid van Moolenbroek	  /dev/random or an equivalent, it is used by default.  A
208*00b67f09SDavid van Moolenbroek	  source of entropy can also be defined using the random-device
209*00b67f09SDavid van Moolenbroek	  option in named.conf.
210*00b67f09SDavid van Moolenbroek	</para>
211*00b67f09SDavid van Moolenbroek      </answer>
212*00b67f09SDavid van Moolenbroek    </qandaentry>
213*00b67f09SDavid van Moolenbroek
214*00b67f09SDavid van Moolenbroek    <qandaentry>
215*00b67f09SDavid van Moolenbroek      <!-- configuration -->
216*00b67f09SDavid van Moolenbroek      <question>
217*00b67f09SDavid van Moolenbroek	<para>
218*00b67f09SDavid van Moolenbroek	  I'm trying to use TSIG to authenticate dynamic updates or
219*00b67f09SDavid van Moolenbroek	  zone transfers.  I'm sure I have the keys set up correctly,
220*00b67f09SDavid van Moolenbroek	  but the server is rejecting the TSIG.  Why?
221*00b67f09SDavid van Moolenbroek	</para>
222*00b67f09SDavid van Moolenbroek      </question>
223*00b67f09SDavid van Moolenbroek      <answer>
224*00b67f09SDavid van Moolenbroek	<para>
225*00b67f09SDavid van Moolenbroek	  This may be a clock skew problem.  Check that the the clocks
226*00b67f09SDavid van Moolenbroek	  on the client and server are properly synchronised (e.g.,
227*00b67f09SDavid van Moolenbroek	  using ntp).
228*00b67f09SDavid van Moolenbroek	</para>
229*00b67f09SDavid van Moolenbroek      </answer>
230*00b67f09SDavid van Moolenbroek    </qandaentry>
231*00b67f09SDavid van Moolenbroek
232*00b67f09SDavid van Moolenbroek    <qandaentry>
233*00b67f09SDavid van Moolenbroek      <question>
234*00b67f09SDavid van Moolenbroek	<para>
235*00b67f09SDavid van Moolenbroek	  I see a log message like the following.  Why?
236*00b67f09SDavid van Moolenbroek	</para>
237*00b67f09SDavid van Moolenbroek	<para>
238*00b67f09SDavid van Moolenbroek	  couldn't open pid file '/var/run/named.pid': Permission denied
239*00b67f09SDavid van Moolenbroek	</para>
240*00b67f09SDavid van Moolenbroek      </question>
241*00b67f09SDavid van Moolenbroek      <answer>
242*00b67f09SDavid van Moolenbroek	<para>
243*00b67f09SDavid van Moolenbroek	  You are most likely running named as a non-root user, and
244*00b67f09SDavid van Moolenbroek	  that user does not have permission to write in /var/run.
245*00b67f09SDavid van Moolenbroek	  The common ways of fixing this are to create a /var/run/named
246*00b67f09SDavid van Moolenbroek	  directory owned by the named user and set pid-file to
247*00b67f09SDavid van Moolenbroek	  "/var/run/named/named.pid", or set pid-file to "named.pid",
248*00b67f09SDavid van Moolenbroek	  which will put the file in the directory specified by the
249*00b67f09SDavid van Moolenbroek	  directory option (which, in this case, must be writable by
250*00b67f09SDavid van Moolenbroek	  the user named is running as).
251*00b67f09SDavid van Moolenbroek	</para>
252*00b67f09SDavid van Moolenbroek      </answer>
253*00b67f09SDavid van Moolenbroek    </qandaentry>
254*00b67f09SDavid van Moolenbroek
255*00b67f09SDavid van Moolenbroek    <qandaentry>
256*00b67f09SDavid van Moolenbroek      <question>
257*00b67f09SDavid van Moolenbroek	<para>
258*00b67f09SDavid van Moolenbroek	  I can query the nameserver from the nameserver but not from other
259*00b67f09SDavid van Moolenbroek	  machines.  Why?
260*00b67f09SDavid van Moolenbroek	</para>
261*00b67f09SDavid van Moolenbroek      </question>
262*00b67f09SDavid van Moolenbroek      <answer>
263*00b67f09SDavid van Moolenbroek	<para>
264*00b67f09SDavid van Moolenbroek	  This is usually the result of the firewall configuration stopping
265*00b67f09SDavid van Moolenbroek	  the queries and / or the replies.
266*00b67f09SDavid van Moolenbroek	</para>
267*00b67f09SDavid van Moolenbroek      </answer>
268*00b67f09SDavid van Moolenbroek    </qandaentry>
269*00b67f09SDavid van Moolenbroek
270*00b67f09SDavid van Moolenbroek    <qandaentry>
271*00b67f09SDavid van Moolenbroek      <question>
272*00b67f09SDavid van Moolenbroek	<para>
273*00b67f09SDavid van Moolenbroek	  How can I make a server a slave for both an internal and
274*00b67f09SDavid van Moolenbroek	  an external view at the same time?  When I tried, both views
275*00b67f09SDavid van Moolenbroek	  on the slave were transferred from the same view on the master.
276*00b67f09SDavid van Moolenbroek	</para>
277*00b67f09SDavid van Moolenbroek      </question>
278*00b67f09SDavid van Moolenbroek      <answer>
279*00b67f09SDavid van Moolenbroek	<para>
280*00b67f09SDavid van Moolenbroek	  You will need to give the master and slave multiple IP
281*00b67f09SDavid van Moolenbroek	  addresses and use those to make sure you reach the correct
282*00b67f09SDavid van Moolenbroek	  view on the other machine.
283*00b67f09SDavid van Moolenbroek	</para>
284*00b67f09SDavid van Moolenbroek	<informalexample>
285*00b67f09SDavid van Moolenbroek	  <programlisting>
286*00b67f09SDavid van MoolenbroekMaster: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
287*00b67f09SDavid van Moolenbroek    internal:
288*00b67f09SDavid van Moolenbroek	match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
289*00b67f09SDavid van Moolenbroek		notify-source 10.0.1.1;
290*00b67f09SDavid van Moolenbroek		transfer-source 10.0.1.1;
291*00b67f09SDavid van Moolenbroek		query-source address 10.0.1.1;
292*00b67f09SDavid van Moolenbroek    external:
293*00b67f09SDavid van Moolenbroek	match-clients { any; };
294*00b67f09SDavid van Moolenbroek	recursion no;	// don't offer recursion to the world
295*00b67f09SDavid van Moolenbroek	notify-source 10.0.1.2;
296*00b67f09SDavid van Moolenbroek	transfer-source 10.0.1.2;
297*00b67f09SDavid van Moolenbroek	query-source address 10.0.1.2;
298*00b67f09SDavid van Moolenbroek
299*00b67f09SDavid van MoolenbroekSlave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
300*00b67f09SDavid van Moolenbroek    internal:
301*00b67f09SDavid van Moolenbroek	match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
302*00b67f09SDavid van Moolenbroek	notify-source 10.0.1.3;
303*00b67f09SDavid van Moolenbroek	transfer-source 10.0.1.3;
304*00b67f09SDavid van Moolenbroek	query-source address 10.0.1.3;
305*00b67f09SDavid van Moolenbroek   external:
306*00b67f09SDavid van Moolenbroek	match-clients { any; };
307*00b67f09SDavid van Moolenbroek	recursion no;	// don't offer recursion to the world
308*00b67f09SDavid van Moolenbroek	notify-source 10.0.1.4;
309*00b67f09SDavid van Moolenbroek	transfer-source 10.0.1.4;
310*00b67f09SDavid van Moolenbroek	query-source address 10.0.1.4;</programlisting>
311*00b67f09SDavid van Moolenbroek	</informalexample>
312*00b67f09SDavid van Moolenbroek	<para>
313*00b67f09SDavid van Moolenbroek	  You put the external address on the alias so that all the other
314*00b67f09SDavid van Moolenbroek	  dns clients on these boxes see the internal view by default.
315*00b67f09SDavid van Moolenbroek	</para>
316*00b67f09SDavid van Moolenbroek      </answer>
317*00b67f09SDavid van Moolenbroek      <answer>
318*00b67f09SDavid van Moolenbroek	<para>
319*00b67f09SDavid van Moolenbroek	  BIND 9.3 and later: Use TSIG to select the appropriate view.
320*00b67f09SDavid van Moolenbroek	</para>
321*00b67f09SDavid van Moolenbroek	<informalexample>
322*00b67f09SDavid van Moolenbroek	  <programlisting>
323*00b67f09SDavid van MoolenbroekMaster 10.0.1.1:
324*00b67f09SDavid van Moolenbroek	key "external" {
325*00b67f09SDavid van Moolenbroek		algorithm hmac-sha256;
326*00b67f09SDavid van Moolenbroek		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
327*00b67f09SDavid van Moolenbroek	};
328*00b67f09SDavid van Moolenbroek	view "internal" {
329*00b67f09SDavid van Moolenbroek		match-clients { !key external; // reject message ment for the
330*00b67f09SDavid van Moolenbroek					       // external view.
331*00b67f09SDavid van Moolenbroek				10.0.1/24; };  // accept from these addresses.
332*00b67f09SDavid van Moolenbroek		...
333*00b67f09SDavid van Moolenbroek	};
334*00b67f09SDavid van Moolenbroek	view "external" {
335*00b67f09SDavid van Moolenbroek		match-clients { key external; any; };
336*00b67f09SDavid van Moolenbroek		server 10.0.1.2 { keys external; };  // tag messages from the
337*00b67f09SDavid van Moolenbroek						     // external view to the
338*00b67f09SDavid van Moolenbroek						     // other servers for the
339*00b67f09SDavid van Moolenbroek						     // view.
340*00b67f09SDavid van Moolenbroek		recursion no;
341*00b67f09SDavid van Moolenbroek		...
342*00b67f09SDavid van Moolenbroek	};
343*00b67f09SDavid van Moolenbroek
344*00b67f09SDavid van MoolenbroekSlave 10.0.1.2:
345*00b67f09SDavid van Moolenbroek	key "external" {
346*00b67f09SDavid van Moolenbroek		algorithm hmac-sha256;
347*00b67f09SDavid van Moolenbroek		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
348*00b67f09SDavid van Moolenbroek	};
349*00b67f09SDavid van Moolenbroek	view "internal" {
350*00b67f09SDavid van Moolenbroek		match-clients { !key external; 10.0.1/24; };
351*00b67f09SDavid van Moolenbroek		...
352*00b67f09SDavid van Moolenbroek	};
353*00b67f09SDavid van Moolenbroek	view "external" {
354*00b67f09SDavid van Moolenbroek		match-clients { key external; any; };
355*00b67f09SDavid van Moolenbroek		server 10.0.1.1 { keys external; };
356*00b67f09SDavid van Moolenbroek		recursion no;
357*00b67f09SDavid van Moolenbroek		...
358*00b67f09SDavid van Moolenbroek	};</programlisting>
359*00b67f09SDavid van Moolenbroek	</informalexample>
360*00b67f09SDavid van Moolenbroek      </answer>
361*00b67f09SDavid van Moolenbroek    </qandaentry>
362*00b67f09SDavid van Moolenbroek
363*00b67f09SDavid van Moolenbroek    <qandaentry>
364*00b67f09SDavid van Moolenbroek      <question>
365*00b67f09SDavid van Moolenbroek	<para>
366*00b67f09SDavid van Moolenbroek	  I get error messages like <quote>multiple RRs of singleton type</quote>
367*00b67f09SDavid van Moolenbroek	  and <quote>CNAME and other data</quote> when transferring a zone.  What
368*00b67f09SDavid van Moolenbroek	  does this mean?
369*00b67f09SDavid van Moolenbroek	</para>
370*00b67f09SDavid van Moolenbroek      </question>
371*00b67f09SDavid van Moolenbroek      <answer>
372*00b67f09SDavid van Moolenbroek	<para>
373*00b67f09SDavid van Moolenbroek	  These indicate a malformed master zone.  You can identify
374*00b67f09SDavid van Moolenbroek	  the exact records involved by transferring the zone using
375*00b67f09SDavid van Moolenbroek	  dig then running named-checkzone on it.
376*00b67f09SDavid van Moolenbroek	</para>
377*00b67f09SDavid van Moolenbroek	<informalexample>
378*00b67f09SDavid van Moolenbroek	  <programlisting>
379*00b67f09SDavid van Moolenbroekdig axfr example.com @master-server &gt; tmp
380*00b67f09SDavid van Moolenbroeknamed-checkzone example.com tmp</programlisting>
381*00b67f09SDavid van Moolenbroek	</informalexample>
382*00b67f09SDavid van Moolenbroek	<para>
383*00b67f09SDavid van Moolenbroek	  A CNAME record cannot exist with the same name as another record
384*00b67f09SDavid van Moolenbroek	  except for the DNSSEC records which prove its existence (NSEC).
385*00b67f09SDavid van Moolenbroek	</para>
386*00b67f09SDavid van Moolenbroek	<para>
387*00b67f09SDavid van Moolenbroek	  RFC 1034, Section 3.6.2: <quote>If a CNAME RR is present at a node,
388*00b67f09SDavid van Moolenbroek	  no other data should be present; this ensures that the data for a
389*00b67f09SDavid van Moolenbroek	  canonical name and its aliases cannot be different.  This rule also
390*00b67f09SDavid van Moolenbroek	  insures that a cached CNAME can be used without checking with an
391*00b67f09SDavid van Moolenbroek	  authoritative server for other RR types.</quote>
392*00b67f09SDavid van Moolenbroek	</para>
393*00b67f09SDavid van Moolenbroek      </answer>
394*00b67f09SDavid van Moolenbroek    </qandaentry>
395*00b67f09SDavid van Moolenbroek
396*00b67f09SDavid van Moolenbroek    <qandaentry>
397*00b67f09SDavid van Moolenbroek      <question>
398*00b67f09SDavid van Moolenbroek	<para>
399*00b67f09SDavid van Moolenbroek	  I get error messages like <quote>named.conf:99: unexpected end
400*00b67f09SDavid van Moolenbroek	  of input</quote> where 99 is the last line of named.conf.
401*00b67f09SDavid van Moolenbroek	</para>
402*00b67f09SDavid van Moolenbroek      </question>
403*00b67f09SDavid van Moolenbroek      <answer>
404*00b67f09SDavid van Moolenbroek	<para>
405*00b67f09SDavid van Moolenbroek	  There are unbalanced quotes in named.conf.
406*00b67f09SDavid van Moolenbroek	</para>
407*00b67f09SDavid van Moolenbroek      </answer>
408*00b67f09SDavid van Moolenbroek      <answer>
409*00b67f09SDavid van Moolenbroek	<para>
410*00b67f09SDavid van Moolenbroek	  Some text editors (notepad and wordpad) fail to put a line
411*00b67f09SDavid van Moolenbroek	  title indication (e.g. CR/LF) on the last line of a
412*00b67f09SDavid van Moolenbroek	  text file.  This can be fixed by "adding" a blank line to
413*00b67f09SDavid van Moolenbroek	  the end of the file.  Named expects to see EOF immediately
414*00b67f09SDavid van Moolenbroek	  after EOL and treats text files where this is not met as
415*00b67f09SDavid van Moolenbroek	  truncated.
416*00b67f09SDavid van Moolenbroek	</para>
417*00b67f09SDavid van Moolenbroek      </answer>
418*00b67f09SDavid van Moolenbroek    </qandaentry>
419*00b67f09SDavid van Moolenbroek
420*00b67f09SDavid van Moolenbroek    <qandaentry>
421*00b67f09SDavid van Moolenbroek      <question>
422*00b67f09SDavid van Moolenbroek	<para>
423*00b67f09SDavid van Moolenbroek	  How do I share a dynamic zone between multiple views?
424*00b67f09SDavid van Moolenbroek	</para>
425*00b67f09SDavid van Moolenbroek      </question>
426*00b67f09SDavid van Moolenbroek      <answer>
427*00b67f09SDavid van Moolenbroek	<para>
428*00b67f09SDavid van Moolenbroek	  You choose one view to be master and the second a slave and
429*00b67f09SDavid van Moolenbroek	  transfer the zone between views.
430*00b67f09SDavid van Moolenbroek	</para>
431*00b67f09SDavid van Moolenbroek	<informalexample>
432*00b67f09SDavid van Moolenbroek	  <programlisting>
433*00b67f09SDavid van MoolenbroekMaster 10.0.1.1:
434*00b67f09SDavid van Moolenbroek	key "external" {
435*00b67f09SDavid van Moolenbroek		algorithm hmac-sha256;
436*00b67f09SDavid van Moolenbroek		secret "xxxxxxxxxxxxxxxxxxxxxxxx";
437*00b67f09SDavid van Moolenbroek	};
438*00b67f09SDavid van Moolenbroek
439*00b67f09SDavid van Moolenbroek	key "mykey" {
440*00b67f09SDavid van Moolenbroek		algorithm hmac-sha256;
441*00b67f09SDavid van Moolenbroek		secret "yyyyyyyyyyyyyyyyyyyyyyyy";
442*00b67f09SDavid van Moolenbroek	};
443*00b67f09SDavid van Moolenbroek
444*00b67f09SDavid van Moolenbroek	view "internal" {
445*00b67f09SDavid van Moolenbroek		match-clients { !key external; 10.0.1/24; };
446*00b67f09SDavid van Moolenbroek		server 10.0.1.1 {
447*00b67f09SDavid van Moolenbroek			/* Deliver notify messages to external view. */
448*00b67f09SDavid van Moolenbroek			keys { external; };
449*00b67f09SDavid van Moolenbroek		};
450*00b67f09SDavid van Moolenbroek		zone "example.com" {
451*00b67f09SDavid van Moolenbroek			type master;
452*00b67f09SDavid van Moolenbroek			file "internal/example.db";
453*00b67f09SDavid van Moolenbroek			allow-update { key mykey; };
454*00b67f09SDavid van Moolenbroek			also-notify { 10.0.1.1; };
455*00b67f09SDavid van Moolenbroek		};
456*00b67f09SDavid van Moolenbroek	};
457*00b67f09SDavid van Moolenbroek
458*00b67f09SDavid van Moolenbroek	view "external" {
459*00b67f09SDavid van Moolenbroek		match-clients { key external; any; };
460*00b67f09SDavid van Moolenbroek		zone "example.com" {
461*00b67f09SDavid van Moolenbroek			type slave;
462*00b67f09SDavid van Moolenbroek			file "external/example.db";
463*00b67f09SDavid van Moolenbroek			masters { 10.0.1.1; };
464*00b67f09SDavid van Moolenbroek			transfer-source 10.0.1.1;
465*00b67f09SDavid van Moolenbroek			// allow-update-forwarding { any; };
466*00b67f09SDavid van Moolenbroek			// allow-notify { ... };
467*00b67f09SDavid van Moolenbroek		};
468*00b67f09SDavid van Moolenbroek	};</programlisting>
469*00b67f09SDavid van Moolenbroek	</informalexample>
470*00b67f09SDavid van Moolenbroek      </answer>
471*00b67f09SDavid van Moolenbroek    </qandaentry>
472*00b67f09SDavid van Moolenbroek
473*00b67f09SDavid van Moolenbroek    <qandaentry>
474*00b67f09SDavid van Moolenbroek      <question>
475*00b67f09SDavid van Moolenbroek	<para>
476*00b67f09SDavid van Moolenbroek	  I get a error message like <quote>zone wireless.ietf56.ietf.org/IN:
477*00b67f09SDavid van Moolenbroek	  loading master file primaries/wireless.ietf56.ietf.org: no
478*00b67f09SDavid van Moolenbroek	  owner</quote>.
479*00b67f09SDavid van Moolenbroek	</para>
480*00b67f09SDavid van Moolenbroek      </question>
481*00b67f09SDavid van Moolenbroek      <answer>
482*00b67f09SDavid van Moolenbroek	<para>
483*00b67f09SDavid van Moolenbroek	  This error is produced when a line in the master file
484*00b67f09SDavid van Moolenbroek	  contains leading white space (tab/space) but there is no
485*00b67f09SDavid van Moolenbroek	  current record owner name to inherit the name from.  Usually
486*00b67f09SDavid van Moolenbroek	  this is the result of putting white space before a comment,
487*00b67f09SDavid van Moolenbroek	  forgetting the "@" for the SOA record, or indenting the master
488*00b67f09SDavid van Moolenbroek	  file.
489*00b67f09SDavid van Moolenbroek	</para>
490*00b67f09SDavid van Moolenbroek      </answer>
491*00b67f09SDavid van Moolenbroek    </qandaentry>
492*00b67f09SDavid van Moolenbroek
493*00b67f09SDavid van Moolenbroek    <qandaentry>
494*00b67f09SDavid van Moolenbroek      <question>
495*00b67f09SDavid van Moolenbroek	<para>
496*00b67f09SDavid van Moolenbroek	  Why are my logs in GMT (UTC).
497*00b67f09SDavid van Moolenbroek	</para>
498*00b67f09SDavid van Moolenbroek      </question>
499*00b67f09SDavid van Moolenbroek      <answer>
500*00b67f09SDavid van Moolenbroek	<para>
501*00b67f09SDavid van Moolenbroek	  You are running chrooted (-t) and have not supplied local timezone
502*00b67f09SDavid van Moolenbroek	  information in the chroot area.
503*00b67f09SDavid van Moolenbroek	</para>
504*00b67f09SDavid van Moolenbroek	<simplelist>
505*00b67f09SDavid van Moolenbroek	  <member>FreeBSD: /etc/localtime</member>
506*00b67f09SDavid van Moolenbroek	  <member>Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo</member>
507*00b67f09SDavid van Moolenbroek	  <member>OSF: /etc/zoneinfo/localtime</member>
508*00b67f09SDavid van Moolenbroek	  </simplelist>
509*00b67f09SDavid van Moolenbroek	<para>
510*00b67f09SDavid van Moolenbroek	  See also tzset(3) and zic(8).
511*00b67f09SDavid van Moolenbroek	</para>
512*00b67f09SDavid van Moolenbroek      </answer>
513*00b67f09SDavid van Moolenbroek    </qandaentry>
514*00b67f09SDavid van Moolenbroek
515*00b67f09SDavid van Moolenbroek    <qandaentry>
516*00b67f09SDavid van Moolenbroek      <question>
517*00b67f09SDavid van Moolenbroek	<para>
518*00b67f09SDavid van Moolenbroek	  I get <quote>rndc: connect failed: connection refused</quote> when
519*00b67f09SDavid van Moolenbroek	  I try to run rndc.
520*00b67f09SDavid van Moolenbroek	</para>
521*00b67f09SDavid van Moolenbroek      </question>
522*00b67f09SDavid van Moolenbroek      <answer>
523*00b67f09SDavid van Moolenbroek	<para>
524*00b67f09SDavid van Moolenbroek	  This is usually a configuration error.
525*00b67f09SDavid van Moolenbroek	</para>
526*00b67f09SDavid van Moolenbroek	<para>
527*00b67f09SDavid van Moolenbroek	  First ensure that named is running and no errors are being
528*00b67f09SDavid van Moolenbroek	  reported at startup (/var/log/messages or equivalent).
529*00b67f09SDavid van Moolenbroek	  Running "named -g &lt;usual arguments&gt;" from a title
530*00b67f09SDavid van Moolenbroek	  can help at this point.
531*00b67f09SDavid van Moolenbroek	</para>
532*00b67f09SDavid van Moolenbroek	<para>
533*00b67f09SDavid van Moolenbroek	  Secondly ensure that named is configured to use rndc either
534*00b67f09SDavid van Moolenbroek	  by "rndc-confgen -a", rndc-confgen or manually.  The
535*00b67f09SDavid van Moolenbroek	  Administrators Reference manual has details on how to do
536*00b67f09SDavid van Moolenbroek	  this.
537*00b67f09SDavid van Moolenbroek	</para>
538*00b67f09SDavid van Moolenbroek	<para>
539*00b67f09SDavid van Moolenbroek	  Old versions of rndc-confgen used localhost rather than
540*00b67f09SDavid van Moolenbroek	  127.0.0.1 in /etc/rndc.conf for the default server.  Update
541*00b67f09SDavid van Moolenbroek	  /etc/rndc.conf if necessary so that the default server
542*00b67f09SDavid van Moolenbroek	  listed in /etc/rndc.conf matches the addresses used in
543*00b67f09SDavid van Moolenbroek	  named.conf.  "localhost" has two address (127.0.0.1 and
544*00b67f09SDavid van Moolenbroek	  ::1).
545*00b67f09SDavid van Moolenbroek	</para>
546*00b67f09SDavid van Moolenbroek	<para>
547*00b67f09SDavid van Moolenbroek	  If you use "rndc-confgen -a" and named is running with -t or -u
548*00b67f09SDavid van Moolenbroek	  ensure that /etc/rndc.conf has the correct ownership and that
549*00b67f09SDavid van Moolenbroek	  a copy is in the chroot area.  You can do this by re-running
550*00b67f09SDavid van Moolenbroek	  "rndc-confgen -a" with appropriate -t and -u arguments.
551*00b67f09SDavid van Moolenbroek	</para>
552*00b67f09SDavid van Moolenbroek      </answer>
553*00b67f09SDavid van Moolenbroek    </qandaentry>
554*00b67f09SDavid van Moolenbroek
555*00b67f09SDavid van Moolenbroek    <qandaentry>
556*00b67f09SDavid van Moolenbroek      <question>
557*00b67f09SDavid van Moolenbroek	<para>
558*00b67f09SDavid van Moolenbroek	  I get <quote>transfer of 'example.net/IN' from 192.168.4.12#53:
559*00b67f09SDavid van Moolenbroek	  failed while receiving responses: permission denied</quote> error
560*00b67f09SDavid van Moolenbroek	  messages.
561*00b67f09SDavid van Moolenbroek	</para>
562*00b67f09SDavid van Moolenbroek      </question>
563*00b67f09SDavid van Moolenbroek      <answer>
564*00b67f09SDavid van Moolenbroek	<para>
565*00b67f09SDavid van Moolenbroek	  These indicate a filesystem permission error preventing
566*00b67f09SDavid van Moolenbroek	  named creating / renaming the temporary file.  These will
567*00b67f09SDavid van Moolenbroek	  usually also have other associated error messages like
568*00b67f09SDavid van Moolenbroek	</para>
569*00b67f09SDavid van Moolenbroek	<informalexample>
570*00b67f09SDavid van Moolenbroek	  <programlisting>
571*00b67f09SDavid van Moolenbroek"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"</programlisting>
572*00b67f09SDavid van Moolenbroek	</informalexample>
573*00b67f09SDavid van Moolenbroek	<para>
574*00b67f09SDavid van Moolenbroek	  Named needs write permission on the directory containing
575*00b67f09SDavid van Moolenbroek	  the file.  Named writes the new cache file to a temporary
576*00b67f09SDavid van Moolenbroek	  file then renames it to the name specified in named.conf
577*00b67f09SDavid van Moolenbroek	  to ensure that the contents are always complete.  This is
578*00b67f09SDavid van Moolenbroek	  to prevent named loading a partial zone in the event of
579*00b67f09SDavid van Moolenbroek	  power failure or similar interrupting the write of the
580*00b67f09SDavid van Moolenbroek	  master file.
581*00b67f09SDavid van Moolenbroek	</para>
582*00b67f09SDavid van Moolenbroek	<para>
583*00b67f09SDavid van Moolenbroek	  Note file names are relative to the directory specified in
584*00b67f09SDavid van Moolenbroek	  options and any chroot directory  ([&lt;chroot
585*00b67f09SDavid van Moolenbroek	  dir&gt;/][&lt;options dir&gt;]).
586*00b67f09SDavid van Moolenbroek	</para>
587*00b67f09SDavid van Moolenbroek	<informalexample>
588*00b67f09SDavid van Moolenbroek	  <para>
589*00b67f09SDavid van Moolenbroek	    If named is invoked as "named -t /chroot/DNS" with
590*00b67f09SDavid van Moolenbroek	    the following named.conf then "/chroot/DNS/var/named/sl"
591*00b67f09SDavid van Moolenbroek	    needs to be writable by the user named is running as.
592*00b67f09SDavid van Moolenbroek	  </para>
593*00b67f09SDavid van Moolenbroek	  <programlisting>
594*00b67f09SDavid van Moolenbroekoptions {
595*00b67f09SDavid van Moolenbroek	directory "/var/named";
596*00b67f09SDavid van Moolenbroek};
597*00b67f09SDavid van Moolenbroek
598*00b67f09SDavid van Moolenbroekzone "example.net" {
599*00b67f09SDavid van Moolenbroek	type slave;
600*00b67f09SDavid van Moolenbroek	file "sl/example.net";
601*00b67f09SDavid van Moolenbroek	masters { 192.168.4.12; };
602*00b67f09SDavid van Moolenbroek};</programlisting>
603*00b67f09SDavid van Moolenbroek	</informalexample>
604*00b67f09SDavid van Moolenbroek      </answer>
605*00b67f09SDavid van Moolenbroek    </qandaentry>
606*00b67f09SDavid van Moolenbroek
607*00b67f09SDavid van Moolenbroek    <qandaentry>
608*00b67f09SDavid van Moolenbroek      <question>
609*00b67f09SDavid van Moolenbroek	<para>
610*00b67f09SDavid van Moolenbroek	  I want to forward all DNS queries from my caching nameserver to
611*00b67f09SDavid van Moolenbroek	  another server. But there are some domains which have to be
612*00b67f09SDavid van Moolenbroek	  served locally, via rbldnsd.
613*00b67f09SDavid van Moolenbroek	</para>
614*00b67f09SDavid van Moolenbroek	<para>
615*00b67f09SDavid van Moolenbroek	  How do I achieve this ?
616*00b67f09SDavid van Moolenbroek	</para>
617*00b67f09SDavid van Moolenbroek      </question>
618*00b67f09SDavid van Moolenbroek      <answer>
619*00b67f09SDavid van Moolenbroek        <programlisting>
620*00b67f09SDavid van Moolenbroekoptions {
621*00b67f09SDavid van Moolenbroek	forward only;
622*00b67f09SDavid van Moolenbroek	forwarders { &lt;ip.of.primary.nameserver&gt;; };
623*00b67f09SDavid van Moolenbroek};
624*00b67f09SDavid van Moolenbroek
625*00b67f09SDavid van Moolenbroekzone "sbl-xbl.spamhaus.org" {
626*00b67f09SDavid van Moolenbroek	type forward; forward only;
627*00b67f09SDavid van Moolenbroek	forwarders { &lt;ip.of.rbldns.server&gt; port 530; };
628*00b67f09SDavid van Moolenbroek};
629*00b67f09SDavid van Moolenbroek
630*00b67f09SDavid van Moolenbroekzone "list.dsbl.org" {
631*00b67f09SDavid van Moolenbroek	type forward; forward only;
632*00b67f09SDavid van Moolenbroek	forwarders { &lt;ip.of.rbldns.server&gt; port 530; };
633*00b67f09SDavid van Moolenbroek};
634*00b67f09SDavid van Moolenbroek        </programlisting>
635*00b67f09SDavid van Moolenbroek      </answer>
636*00b67f09SDavid van Moolenbroek    </qandaentry>
637*00b67f09SDavid van Moolenbroek
638*00b67f09SDavid van Moolenbroek    <qandaentry>
639*00b67f09SDavid van Moolenbroek      <question>
640*00b67f09SDavid van Moolenbroek	<para>
641*00b67f09SDavid van Moolenbroek	  Can you help me understand how BIND 9 uses memory to store
642*00b67f09SDavid van Moolenbroek	  DNS zones?
643*00b67f09SDavid van Moolenbroek	</para>
644*00b67f09SDavid van Moolenbroek	<para>
645*00b67f09SDavid van Moolenbroek	  Some times it seems to take several times the amount of
646*00b67f09SDavid van Moolenbroek	  memory it needs to store the zone.
647*00b67f09SDavid van Moolenbroek	</para>
648*00b67f09SDavid van Moolenbroek      </question>
649*00b67f09SDavid van Moolenbroek      <answer>
650*00b67f09SDavid van Moolenbroek	<para>
651*00b67f09SDavid van Moolenbroek	  When reloading a zone named my have multiple copies of
652*00b67f09SDavid van Moolenbroek	  the zone in memory at one time.  The zone it is serving
653*00b67f09SDavid van Moolenbroek	  and the one it is loading.  If reloads are ultra fast it
654*00b67f09SDavid van Moolenbroek	  can have more still.
655*00b67f09SDavid van Moolenbroek	</para>
656*00b67f09SDavid van Moolenbroek	<para>
657*00b67f09SDavid van Moolenbroek	  e.g.  Ones that are transferring out, the one that it is
658*00b67f09SDavid van Moolenbroek	  serving and the one that is loading.
659*00b67f09SDavid van Moolenbroek	</para>
660*00b67f09SDavid van Moolenbroek	<para>
661*00b67f09SDavid van Moolenbroek	  BIND 8 destroyed the zone before loading and also killed
662*00b67f09SDavid van Moolenbroek	  off outgoing transfers of the zone.
663*00b67f09SDavid van Moolenbroek	</para>
664*00b67f09SDavid van Moolenbroek	<para>
665*00b67f09SDavid van Moolenbroek	  The new strategy allows slaves to get copies of the new
666*00b67f09SDavid van Moolenbroek	  zone regardless of how often the master is loaded compared
667*00b67f09SDavid van Moolenbroek	  to the transfer time.  The slave might skip some intermediate
668*00b67f09SDavid van Moolenbroek	  versions but the transfers will complete and it will keep
669*00b67f09SDavid van Moolenbroek	  reasonably in sync with the master.
670*00b67f09SDavid van Moolenbroek	</para>
671*00b67f09SDavid van Moolenbroek	<para>
672*00b67f09SDavid van Moolenbroek	  The new strategy also allows the master to recover from
673*00b67f09SDavid van Moolenbroek	  syntax and other errors in the master file as it still
674*00b67f09SDavid van Moolenbroek	  has an in-core copy of the old contents.
675*00b67f09SDavid van Moolenbroek	</para>
676*00b67f09SDavid van Moolenbroek      </answer>
677*00b67f09SDavid van Moolenbroek    </qandaentry>
678*00b67f09SDavid van Moolenbroek
679*00b67f09SDavid van Moolenbroek    <qandaentry>
680*00b67f09SDavid van Moolenbroek      <question>
681*00b67f09SDavid van Moolenbroek	<para>
682*00b67f09SDavid van Moolenbroek	  I want to use IPv6 locally but I don't have a external IPv6
683*00b67f09SDavid van Moolenbroek	  connection.  External lookups are slow.
684*00b67f09SDavid van Moolenbroek	</para>
685*00b67f09SDavid van Moolenbroek      </question>
686*00b67f09SDavid van Moolenbroek      <answer>
687*00b67f09SDavid van Moolenbroek	<para>
688*00b67f09SDavid van Moolenbroek	  You can use server clauses to stop named making external lookups
689*00b67f09SDavid van Moolenbroek	  over IPv6.
690*00b67f09SDavid van Moolenbroek	</para>
691*00b67f09SDavid van Moolenbroek        <programlisting>
692*00b67f09SDavid van Moolenbroekserver fd81:ec6c:bd62::/48 { bogus no; }; // site ULA prefix
693*00b67f09SDavid van Moolenbroekserver ::/0 { bogus yes; };
694*00b67f09SDavid van Moolenbroek</programlisting>
695*00b67f09SDavid van Moolenbroek      </answer>
696*00b67f09SDavid van Moolenbroek    </qandaentry>
697*00b67f09SDavid van Moolenbroek
698*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Configuration and Setup Questions -->
699*00b67f09SDavid van Moolenbroek
700*00b67f09SDavid van Moolenbroek    <qandadiv><title>Operations Questions</title>
701*00b67f09SDavid van Moolenbroek
702*00b67f09SDavid van Moolenbroek    <qandaentry>
703*00b67f09SDavid van Moolenbroek      <question>
704*00b67f09SDavid van Moolenbroek	<para>
705*00b67f09SDavid van Moolenbroek	  How to change the nameservers for a zone?
706*00b67f09SDavid van Moolenbroek	</para>
707*00b67f09SDavid van Moolenbroek      </question>
708*00b67f09SDavid van Moolenbroek      <answer>
709*00b67f09SDavid van Moolenbroek	<para>
710*00b67f09SDavid van Moolenbroek	  Step 1: Ensure all nameservers, new and old, are serving the
711*00b67f09SDavid van Moolenbroek	  same zone content.
712*00b67f09SDavid van Moolenbroek	</para>
713*00b67f09SDavid van Moolenbroek	<para>
714*00b67f09SDavid van Moolenbroek	  Step 2: Work out the maximum TTL of the NS RRset in the parent and child
715*00b67f09SDavid van Moolenbroek	  zones.  This is the time it will take caches to be clear of a
716*00b67f09SDavid van Moolenbroek	  particular version of the NS RRset.
717*00b67f09SDavid van Moolenbroek	  If you are just removing nameservers you can skip to Step 6.
718*00b67f09SDavid van Moolenbroek	</para>
719*00b67f09SDavid van Moolenbroek	<para>
720*00b67f09SDavid van Moolenbroek	  Step 3: Add new nameservers to the NS RRset for the zone and
721*00b67f09SDavid van Moolenbroek	  wait until all the servers for the zone are answering with this
722*00b67f09SDavid van Moolenbroek	  new NS RRset.
723*00b67f09SDavid van Moolenbroek	</para>
724*00b67f09SDavid van Moolenbroek	<para>
725*00b67f09SDavid van Moolenbroek	  Step 4: Inform the parent zone of the new NS RRset then wait for all the
726*00b67f09SDavid van Moolenbroek	  parent servers to be answering with the new NS RRset.
727*00b67f09SDavid van Moolenbroek	</para>
728*00b67f09SDavid van Moolenbroek	<para>
729*00b67f09SDavid van Moolenbroek	  Step 5: Wait for cache to be clear of the old NS RRset.
730*00b67f09SDavid van Moolenbroek	  See Step 2 for how long.
731*00b67f09SDavid van Moolenbroek	  If you are just adding nameservers you are done.
732*00b67f09SDavid van Moolenbroek	</para>
733*00b67f09SDavid van Moolenbroek	<para>
734*00b67f09SDavid van Moolenbroek	  Step 6: Remove any old nameservers from the zones NS RRset and
735*00b67f09SDavid van Moolenbroek	  wait for all the servers for the zone to be serving the new NS RRset.
736*00b67f09SDavid van Moolenbroek	</para>
737*00b67f09SDavid van Moolenbroek	<para>
738*00b67f09SDavid van Moolenbroek	  Step 7: Inform the parent zone of the new NS RRset then wait for all the
739*00b67f09SDavid van Moolenbroek	  parent servers to be answering with the new NS RRset.
740*00b67f09SDavid van Moolenbroek	</para>
741*00b67f09SDavid van Moolenbroek	<para>
742*00b67f09SDavid van Moolenbroek	  Step 8: Wait for cache to be clear of the old NS RRset.
743*00b67f09SDavid van Moolenbroek	  See Step 2 for how long.
744*00b67f09SDavid van Moolenbroek	</para>
745*00b67f09SDavid van Moolenbroek	<para>
746*00b67f09SDavid van Moolenbroek	  Step 9: Turn off the old nameservers or remove the zone entry from
747*00b67f09SDavid van Moolenbroek	  the configuration of the old nameservers.
748*00b67f09SDavid van Moolenbroek	</para>
749*00b67f09SDavid van Moolenbroek	<para>
750*00b67f09SDavid van Moolenbroek	  Step 10: Increment the serial number and wait for the change to
751*00b67f09SDavid van Moolenbroek	  be visible in all nameservers for the zone.  This ensures that
752*00b67f09SDavid van Moolenbroek	  zone transfers are still working after the old servers are
753*00b67f09SDavid van Moolenbroek	  decommissioned.
754*00b67f09SDavid van Moolenbroek	</para>
755*00b67f09SDavid van Moolenbroek	<para>
756*00b67f09SDavid van Moolenbroek	  Note: the above procedure is designed to be transparent
757*00b67f09SDavid van Moolenbroek	  to dns clients.  Decommissioning the old servers too early
758*00b67f09SDavid van Moolenbroek	  will result in some clients not being able to look up
759*00b67f09SDavid van Moolenbroek	  answers in the zone.
760*00b67f09SDavid van Moolenbroek	</para>
761*00b67f09SDavid van Moolenbroek	<para>
762*00b67f09SDavid van Moolenbroek	  Note: while it is possible to run the addition and removal
763*00b67f09SDavid van Moolenbroek	  stages together it is not recommended.
764*00b67f09SDavid van Moolenbroek	</para>
765*00b67f09SDavid van Moolenbroek      </answer>
766*00b67f09SDavid van Moolenbroek    </qandaentry>
767*00b67f09SDavid van Moolenbroek
768*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Operations Questions -->
769*00b67f09SDavid van Moolenbroek
770*00b67f09SDavid van Moolenbroek    <qandadiv><title>General Questions</title>
771*00b67f09SDavid van Moolenbroek
772*00b67f09SDavid van Moolenbroek    <qandaentry>
773*00b67f09SDavid van Moolenbroek      <question>
774*00b67f09SDavid van Moolenbroek	<para>
775*00b67f09SDavid van Moolenbroek	  I keep getting log messages like the following.  Why?
776*00b67f09SDavid van Moolenbroek	</para>
777*00b67f09SDavid van Moolenbroek	<para>
778*00b67f09SDavid van Moolenbroek	  Dec  4 23:47:59 client 10.0.0.1#1355: updating zone
779*00b67f09SDavid van Moolenbroek	  'example.com/IN': update failed: 'RRset exists (value
780*00b67f09SDavid van Moolenbroek	  dependent)' prerequisite not satisfied (NXRRSET)
781*00b67f09SDavid van Moolenbroek	</para>
782*00b67f09SDavid van Moolenbroek      </question>
783*00b67f09SDavid van Moolenbroek      <answer>
784*00b67f09SDavid van Moolenbroek	<para>
785*00b67f09SDavid van Moolenbroek	  DNS updates allow the update request to test to see if
786*00b67f09SDavid van Moolenbroek	  certain conditions are met prior to proceeding with the
787*00b67f09SDavid van Moolenbroek	  update.  The message above is saying that conditions were
788*00b67f09SDavid van Moolenbroek	  not met and the update is not proceeding.  See doc/rfc/rfc2136.txt
789*00b67f09SDavid van Moolenbroek	  for more details on prerequisites.
790*00b67f09SDavid van Moolenbroek	</para>
791*00b67f09SDavid van Moolenbroek      </answer>
792*00b67f09SDavid van Moolenbroek    </qandaentry>
793*00b67f09SDavid van Moolenbroek
794*00b67f09SDavid van Moolenbroek    <qandaentry>
795*00b67f09SDavid van Moolenbroek      <question>
796*00b67f09SDavid van Moolenbroek	<para>
797*00b67f09SDavid van Moolenbroek	  I keep getting log messages like the following.  Why?
798*00b67f09SDavid van Moolenbroek	</para>
799*00b67f09SDavid van Moolenbroek	<para>
800*00b67f09SDavid van Moolenbroek	  Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
801*00b67f09SDavid van Moolenbroek	</para>
802*00b67f09SDavid van Moolenbroek      </question>
803*00b67f09SDavid van Moolenbroek      <answer>
804*00b67f09SDavid van Moolenbroek	<para>
805*00b67f09SDavid van Moolenbroek	  Someone is trying to update your DNS data using the RFC2136
806*00b67f09SDavid van Moolenbroek	  Dynamic Update protocol.  Windows 2000 machines have a habit
807*00b67f09SDavid van Moolenbroek	  of sending dynamic update requests to DNS servers without
808*00b67f09SDavid van Moolenbroek	  being specifically configured to do so.  If the update
809*00b67f09SDavid van Moolenbroek	  requests are coming from a Windows 2000 machine, see
810*00b67f09SDavid van Moolenbroek	  <ulink
811*00b67f09SDavid van Moolenbroek	   url="http://support.microsoft.com/support/kb/articles/q246/8/04.asp">
812*00b67f09SDavid van Moolenbroek  &lt;http://support.microsoft.com/support/kb/articles/q246/8/04.asp&gt;</ulink>
813*00b67f09SDavid van Moolenbroek	  for information about how to turn them off.
814*00b67f09SDavid van Moolenbroek	</para>
815*00b67f09SDavid van Moolenbroek      </answer>
816*00b67f09SDavid van Moolenbroek    </qandaentry>
817*00b67f09SDavid van Moolenbroek
818*00b67f09SDavid van Moolenbroek    <qandaentry>
819*00b67f09SDavid van Moolenbroek      <question>
820*00b67f09SDavid van Moolenbroek	<para>
821*00b67f09SDavid van Moolenbroek	  When I do a "dig . ns", many of the A records for the root
822*00b67f09SDavid van Moolenbroek	  servers are missing.  Why?
823*00b67f09SDavid van Moolenbroek	</para>
824*00b67f09SDavid van Moolenbroek      </question>
825*00b67f09SDavid van Moolenbroek      <answer>
826*00b67f09SDavid van Moolenbroek	<para>
827*00b67f09SDavid van Moolenbroek	  This is normal and harmless.  It is a somewhat confusing
828*00b67f09SDavid van Moolenbroek	  side effect of the way BIND 9 does RFC2181 trust ranking
829*00b67f09SDavid van Moolenbroek	  and of the efforts BIND 9 makes to avoid promoting glue
830*00b67f09SDavid van Moolenbroek	  into answers.
831*00b67f09SDavid van Moolenbroek	</para>
832*00b67f09SDavid van Moolenbroek	<para>
833*00b67f09SDavid van Moolenbroek	 When BIND 9 first starts up and primes its cache, it receives
834*00b67f09SDavid van Moolenbroek	 the root server addresses as additional data in an authoritative
835*00b67f09SDavid van Moolenbroek	 response from a root server, and these records are eligible
836*00b67f09SDavid van Moolenbroek	 for inclusion as additional data in responses.  Subsequently
837*00b67f09SDavid van Moolenbroek	 it receives a subset of the root server addresses as
838*00b67f09SDavid van Moolenbroek	 additional data in a non-authoritative (referral) response
839*00b67f09SDavid van Moolenbroek	 from a root server.  This causes the addresses to now be
840*00b67f09SDavid van Moolenbroek	 considered non-authoritative (glue) data, which is not
841*00b67f09SDavid van Moolenbroek	 eligible for inclusion in responses.
842*00b67f09SDavid van Moolenbroek	</para>
843*00b67f09SDavid van Moolenbroek	<para>
844*00b67f09SDavid van Moolenbroek	 The server does have a complete set of root server addresses
845*00b67f09SDavid van Moolenbroek	 cached at all times, it just may not include all of them
846*00b67f09SDavid van Moolenbroek	 as additional data, depending on whether they were last
847*00b67f09SDavid van Moolenbroek	 received as answers or as glue.  You can always look up the
848*00b67f09SDavid van Moolenbroek	 addresses with explicit queries like "dig a.root-servers.net A".
849*00b67f09SDavid van Moolenbroek	</para>
850*00b67f09SDavid van Moolenbroek      </answer>
851*00b67f09SDavid van Moolenbroek    </qandaentry>
852*00b67f09SDavid van Moolenbroek
853*00b67f09SDavid van Moolenbroek    <qandaentry>
854*00b67f09SDavid van Moolenbroek      <question>
855*00b67f09SDavid van Moolenbroek	<para>
856*00b67f09SDavid van Moolenbroek	  Why don't my zones reload when I do an "rndc reload" or SIGHUP?
857*00b67f09SDavid van Moolenbroek	</para>
858*00b67f09SDavid van Moolenbroek      </question>
859*00b67f09SDavid van Moolenbroek      <answer>
860*00b67f09SDavid van Moolenbroek	<para>
861*00b67f09SDavid van Moolenbroek	  A zone can be updated either by editing zone files and
862*00b67f09SDavid van Moolenbroek	  reloading the server or by dynamic update, but not both.
863*00b67f09SDavid van Moolenbroek	  If you have enabled dynamic update for a zone using the
864*00b67f09SDavid van Moolenbroek	  "allow-update" option, you are not supposed to edit the
865*00b67f09SDavid van Moolenbroek	  zone file by hand, and the server will not attempt to reload
866*00b67f09SDavid van Moolenbroek	  it.
867*00b67f09SDavid van Moolenbroek	</para>
868*00b67f09SDavid van Moolenbroek      </answer>
869*00b67f09SDavid van Moolenbroek    </qandaentry>
870*00b67f09SDavid van Moolenbroek
871*00b67f09SDavid van Moolenbroek    <qandaentry>
872*00b67f09SDavid van Moolenbroek      <question>
873*00b67f09SDavid van Moolenbroek	<para>
874*00b67f09SDavid van Moolenbroek	  Why is named listening on UDP port other than 53?
875*00b67f09SDavid van Moolenbroek	</para>
876*00b67f09SDavid van Moolenbroek      </question>
877*00b67f09SDavid van Moolenbroek      <answer>
878*00b67f09SDavid van Moolenbroek	<para>
879*00b67f09SDavid van Moolenbroek	  Named uses a system selected port to make queries of other
880*00b67f09SDavid van Moolenbroek	  nameservers.  This behaviour can be overridden by using
881*00b67f09SDavid van Moolenbroek	  query-source to lock down the port and/or address.  See
882*00b67f09SDavid van Moolenbroek	  also notify-source and transfer-source.
883*00b67f09SDavid van Moolenbroek	</para>
884*00b67f09SDavid van Moolenbroek      </answer>
885*00b67f09SDavid van Moolenbroek    </qandaentry>
886*00b67f09SDavid van Moolenbroek
887*00b67f09SDavid van Moolenbroek    <qandaentry>
888*00b67f09SDavid van Moolenbroek      <question>
889*00b67f09SDavid van Moolenbroek	<para>
890*00b67f09SDavid van Moolenbroek	  I get warning messages like <quote>zone example.com/IN: refresh:
891*00b67f09SDavid van Moolenbroek	  failure trying master 1.2.3.4#53: timed out</quote>.
892*00b67f09SDavid van Moolenbroek	</para>
893*00b67f09SDavid van Moolenbroek      </question>
894*00b67f09SDavid van Moolenbroek      <answer>
895*00b67f09SDavid van Moolenbroek	<para>
896*00b67f09SDavid van Moolenbroek	Check that you can make UDP queries from the slave to the master
897*00b67f09SDavid van Moolenbroek	</para>
898*00b67f09SDavid van Moolenbroek	<informalexample>
899*00b67f09SDavid van Moolenbroek	  <programlisting>
900*00b67f09SDavid van Moolenbroekdig +norec example.com soa @1.2.3.4</programlisting>
901*00b67f09SDavid van Moolenbroek	</informalexample>
902*00b67f09SDavid van Moolenbroek	<para>
903*00b67f09SDavid van Moolenbroek	  You could be generating queries faster than the slave can
904*00b67f09SDavid van Moolenbroek	  cope with.  Lower the serial query rate.
905*00b67f09SDavid van Moolenbroek	</para>
906*00b67f09SDavid van Moolenbroek	<informalexample>
907*00b67f09SDavid van Moolenbroek	  <programlisting>
908*00b67f09SDavid van Moolenbroekserial-query-rate 5; // default 20</programlisting>
909*00b67f09SDavid van Moolenbroek	</informalexample>
910*00b67f09SDavid van Moolenbroek      </answer>
911*00b67f09SDavid van Moolenbroek    </qandaentry>
912*00b67f09SDavid van Moolenbroek
913*00b67f09SDavid van Moolenbroek    <qandaentry>
914*00b67f09SDavid van Moolenbroek      <question>
915*00b67f09SDavid van Moolenbroek	<para>
916*00b67f09SDavid van Moolenbroek	  I don't get RRSIG's returned when I use "dig +dnssec".
917*00b67f09SDavid van Moolenbroek	</para>
918*00b67f09SDavid van Moolenbroek      </question>
919*00b67f09SDavid van Moolenbroek      <answer>
920*00b67f09SDavid van Moolenbroek	<para>
921*00b67f09SDavid van Moolenbroek	  You need to ensure DNSSEC is enabled (dnssec-enable yes;).
922*00b67f09SDavid van Moolenbroek	</para>
923*00b67f09SDavid van Moolenbroek      </answer>
924*00b67f09SDavid van Moolenbroek    </qandaentry>
925*00b67f09SDavid van Moolenbroek
926*00b67f09SDavid van Moolenbroek    <qandaentry>
927*00b67f09SDavid van Moolenbroek      <question>
928*00b67f09SDavid van Moolenbroek	<para>
929*00b67f09SDavid van Moolenbroek	  Can a NS record refer to a CNAME.
930*00b67f09SDavid van Moolenbroek	</para>
931*00b67f09SDavid van Moolenbroek      </question>
932*00b67f09SDavid van Moolenbroek      <answer>
933*00b67f09SDavid van Moolenbroek	<para>
934*00b67f09SDavid van Moolenbroek	  No.  The rules for glue (copies of the *address* records
935*00b67f09SDavid van Moolenbroek	  in the parent zones) and additional section processing do
936*00b67f09SDavid van Moolenbroek	  not allow it to work.
937*00b67f09SDavid van Moolenbroek	</para>
938*00b67f09SDavid van Moolenbroek	<para>
939*00b67f09SDavid van Moolenbroek	  You would have to add both the CNAME and address records
940*00b67f09SDavid van Moolenbroek	  (A/AAAA) as glue to the parent zone and have CNAMEs be
941*00b67f09SDavid van Moolenbroek	  followed when doing additional section processing to make
942*00b67f09SDavid van Moolenbroek	  it work.  No nameserver implementation supports either of
943*00b67f09SDavid van Moolenbroek	  these requirements.
944*00b67f09SDavid van Moolenbroek	</para>
945*00b67f09SDavid van Moolenbroek      </answer>
946*00b67f09SDavid van Moolenbroek    </qandaentry>
947*00b67f09SDavid van Moolenbroek
948*00b67f09SDavid van Moolenbroek    <qandaentry>
949*00b67f09SDavid van Moolenbroek      <question>
950*00b67f09SDavid van Moolenbroek	<para>
951*00b67f09SDavid van Moolenbroek	  What does <quote>RFC 1918 response from Internet for
952*00b67f09SDavid van Moolenbroek	  0.0.0.10.IN-ADDR.ARPA</quote> mean?
953*00b67f09SDavid van Moolenbroek	</para>
954*00b67f09SDavid van Moolenbroek      </question>
955*00b67f09SDavid van Moolenbroek      <answer>
956*00b67f09SDavid van Moolenbroek	<para>
957*00b67f09SDavid van Moolenbroek	  If the IN-ADDR.ARPA name covered refers to a internal address
958*00b67f09SDavid van Moolenbroek	  space you are using then you have failed to follow RFC 1918
959*00b67f09SDavid van Moolenbroek	  usage rules and are leaking queries to the Internet.  You
960*00b67f09SDavid van Moolenbroek	  should establish your own zones for these addresses to prevent
961*00b67f09SDavid van Moolenbroek	  you querying the Internet's name servers for these addresses.
962*00b67f09SDavid van Moolenbroek	  Please see <ulink url="http://as112.net/">&lt;http://as112.net/&gt;</ulink>
963*00b67f09SDavid van Moolenbroek	  for details of the problems you are causing and the counter
964*00b67f09SDavid van Moolenbroek	  measures that have had to be deployed.
965*00b67f09SDavid van Moolenbroek	</para>
966*00b67f09SDavid van Moolenbroek	<para>
967*00b67f09SDavid van Moolenbroek	  If you are not using these private addresses then a client
968*00b67f09SDavid van Moolenbroek	  has queried for them.  You can just ignore the messages,
969*00b67f09SDavid van Moolenbroek	  get the offending client to stop sending you these messages
970*00b67f09SDavid van Moolenbroek	  as they are most probably leaking them or setup your own zones
971*00b67f09SDavid van Moolenbroek	  empty zones to serve answers to these queries.
972*00b67f09SDavid van Moolenbroek	</para>
973*00b67f09SDavid van Moolenbroek	<informalexample>
974*00b67f09SDavid van Moolenbroek	  <programlisting>
975*00b67f09SDavid van Moolenbroekzone "10.IN-ADDR.ARPA" {
976*00b67f09SDavid van Moolenbroek	type master;
977*00b67f09SDavid van Moolenbroek	file "empty";
978*00b67f09SDavid van Moolenbroek};
979*00b67f09SDavid van Moolenbroek
980*00b67f09SDavid van Moolenbroekzone "16.172.IN-ADDR.ARPA" {
981*00b67f09SDavid van Moolenbroek	type master;
982*00b67f09SDavid van Moolenbroek	file "empty";
983*00b67f09SDavid van Moolenbroek};
984*00b67f09SDavid van Moolenbroek
985*00b67f09SDavid van Moolenbroek...
986*00b67f09SDavid van Moolenbroek
987*00b67f09SDavid van Moolenbroekzone "31.172.IN-ADDR.ARPA" {
988*00b67f09SDavid van Moolenbroek	type master;
989*00b67f09SDavid van Moolenbroek	file "empty";
990*00b67f09SDavid van Moolenbroek};
991*00b67f09SDavid van Moolenbroek
992*00b67f09SDavid van Moolenbroekzone "168.192.IN-ADDR.ARPA" {
993*00b67f09SDavid van Moolenbroek	type master;
994*00b67f09SDavid van Moolenbroek	file "empty";
995*00b67f09SDavid van Moolenbroek};
996*00b67f09SDavid van Moolenbroek
997*00b67f09SDavid van Moolenbroekempty:
998*00b67f09SDavid van Moolenbroek@ 10800 IN SOA &lt;name-of-server&gt;. &lt;contact-email&gt;. (
999*00b67f09SDavid van Moolenbroek	       1 3600 1200 604800 10800 )
1000*00b67f09SDavid van Moolenbroek@ 10800 IN NS &lt;name-of-server&gt;.</programlisting>
1001*00b67f09SDavid van Moolenbroek	</informalexample>
1002*00b67f09SDavid van Moolenbroek	<para>
1003*00b67f09SDavid van Moolenbroek	<note>
1004*00b67f09SDavid van Moolenbroek	  Future versions of named are likely to do this automatically.
1005*00b67f09SDavid van Moolenbroek	</note>
1006*00b67f09SDavid van Moolenbroek	</para>
1007*00b67f09SDavid van Moolenbroek      </answer>
1008*00b67f09SDavid van Moolenbroek    </qandaentry>
1009*00b67f09SDavid van Moolenbroek
1010*00b67f09SDavid van Moolenbroek    <qandaentry>
1011*00b67f09SDavid van Moolenbroek      <question>
1012*00b67f09SDavid van Moolenbroek	<para>
1013*00b67f09SDavid van Moolenbroek	  Will named be affected by the 2007 changes to daylight savings
1014*00b67f09SDavid van Moolenbroek	  rules in the US.
1015*00b67f09SDavid van Moolenbroek	</para>
1016*00b67f09SDavid van Moolenbroek      </question>
1017*00b67f09SDavid van Moolenbroek      <answer>
1018*00b67f09SDavid van Moolenbroek	<para>
1019*00b67f09SDavid van Moolenbroek	  No, so long as the machines internal clock (as reported
1020*00b67f09SDavid van Moolenbroek	  by "date -u") remains at UTC.  The only visible change
1021*00b67f09SDavid van Moolenbroek	  if you fail to upgrade your OS, if you are in a affected
1022*00b67f09SDavid van Moolenbroek	  area, will be that log messages will be a hour out during
1023*00b67f09SDavid van Moolenbroek	  the period where the old rules do not match the new rules.
1024*00b67f09SDavid van Moolenbroek	</para>
1025*00b67f09SDavid van Moolenbroek	<para>
1026*00b67f09SDavid van Moolenbroek	  For most OS's this change just means that you need to
1027*00b67f09SDavid van Moolenbroek	  update the conversion rules from UTC to local time.
1028*00b67f09SDavid van Moolenbroek	  Normally this involves updating a file in /etc (which
1029*00b67f09SDavid van Moolenbroek	  sets the default timezone for the machine) and possibly
1030*00b67f09SDavid van Moolenbroek	  a directory which has all the conversion rules for the
1031*00b67f09SDavid van Moolenbroek	  world (e.g. /usr/share/zoneinfo).  When updating the OS
1032*00b67f09SDavid van Moolenbroek	  do not forget to update any chroot areas as well.
1033*00b67f09SDavid van Moolenbroek	  See your OS's documentation for more details.
1034*00b67f09SDavid van Moolenbroek	</para>
1035*00b67f09SDavid van Moolenbroek	<para>
1036*00b67f09SDavid van Moolenbroek	  The local timezone conversion rules can also be done on
1037*00b67f09SDavid van Moolenbroek	  a individual basis by setting the TZ environment variable
1038*00b67f09SDavid van Moolenbroek	  appropriately.  See your OS's documentation for more
1039*00b67f09SDavid van Moolenbroek	  details.
1040*00b67f09SDavid van Moolenbroek	</para>
1041*00b67f09SDavid van Moolenbroek      </answer>
1042*00b67f09SDavid van Moolenbroek    </qandaentry>
1043*00b67f09SDavid van Moolenbroek
1044*00b67f09SDavid van Moolenbroek    <qandaentry>
1045*00b67f09SDavid van Moolenbroek      <question>
1046*00b67f09SDavid van Moolenbroek	<para>
1047*00b67f09SDavid van Moolenbroek	  Is there a bugzilla (or other tool) database that mere
1048*00b67f09SDavid van Moolenbroek	  mortals can have (read-only) access to for bind?
1049*00b67f09SDavid van Moolenbroek	</para>
1050*00b67f09SDavid van Moolenbroek      </question>
1051*00b67f09SDavid van Moolenbroek      <answer>
1052*00b67f09SDavid van Moolenbroek	<para>
1053*00b67f09SDavid van Moolenbroek	  No.  The BIND 9 bug database is kept closed for a number
1054*00b67f09SDavid van Moolenbroek	  of reasons.  These include, but are not limited to, that
1055*00b67f09SDavid van Moolenbroek	  the database contains proprietory information from people
1056*00b67f09SDavid van Moolenbroek	  reporting bugs.  The database has in the past and may in
1057*00b67f09SDavid van Moolenbroek	  future contain unfixed bugs which are capable of bringing
1058*00b67f09SDavid van Moolenbroek	  down most of the Internet's DNS infrastructure.
1059*00b67f09SDavid van Moolenbroek	</para>
1060*00b67f09SDavid van Moolenbroek	<para>
1061*00b67f09SDavid van Moolenbroek	  The release pages for each version contain up to date
1062*00b67f09SDavid van Moolenbroek	  lists of bugs that have been fixed post release.  That
1063*00b67f09SDavid van Moolenbroek	  is as close as we can get to providing a bug database.
1064*00b67f09SDavid van Moolenbroek	</para>
1065*00b67f09SDavid van Moolenbroek      </answer>
1066*00b67f09SDavid van Moolenbroek    </qandaentry>
1067*00b67f09SDavid van Moolenbroek
1068*00b67f09SDavid van Moolenbroek    <qandaentry>
1069*00b67f09SDavid van Moolenbroek      <question>
1070*00b67f09SDavid van Moolenbroek	<para>
1071*00b67f09SDavid van Moolenbroek	  Why do queries for NSEC3 records fail to return the NSEC3 record?
1072*00b67f09SDavid van Moolenbroek	</para>
1073*00b67f09SDavid van Moolenbroek      </question>
1074*00b67f09SDavid van Moolenbroek      <answer>
1075*00b67f09SDavid van Moolenbroek	<para>
1076*00b67f09SDavid van Moolenbroek	  NSEC3 records are strictly meta data and can only be
1077*00b67f09SDavid van Moolenbroek	  returned in the authority section.  This is done so that
1078*00b67f09SDavid van Moolenbroek	  signing the zone using NSEC3 records does not bring names
1079*00b67f09SDavid van Moolenbroek	  into existence that do not exist in the unsigned version
1080*00b67f09SDavid van Moolenbroek	  of the zone.
1081*00b67f09SDavid van Moolenbroek	</para>
1082*00b67f09SDavid van Moolenbroek      </answer>
1083*00b67f09SDavid van Moolenbroek    </qandaentry>
1084*00b67f09SDavid van Moolenbroek
1085*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- General Questions -->
1086*00b67f09SDavid van Moolenbroek
1087*00b67f09SDavid van Moolenbroek    <qandadiv><title>Operating-System Specific Questions</title>
1088*00b67f09SDavid van Moolenbroek
1089*00b67f09SDavid van Moolenbroek    <qandadiv><title>HPUX</title>
1090*00b67f09SDavid van Moolenbroek
1091*00b67f09SDavid van Moolenbroek    <qandaentry>
1092*00b67f09SDavid van Moolenbroek      <question>
1093*00b67f09SDavid van Moolenbroek	<para>I get the following error trying to configure BIND:
1094*00b67f09SDavid van Moolenbroek<programlisting>checking if unistd.h or sys/types.h defines fd_set... no
1095*00b67f09SDavid van Moolenbroekconfigure: error: need either working unistd.h or sys/select.h</programlisting>
1096*00b67f09SDavid van Moolenbroek	</para>
1097*00b67f09SDavid van Moolenbroek      </question>
1098*00b67f09SDavid van Moolenbroek      <answer>
1099*00b67f09SDavid van Moolenbroek	<para>
1100*00b67f09SDavid van Moolenbroek	  You have attempted to configure BIND with the bundled C compiler.
1101*00b67f09SDavid van Moolenbroek	  This compiler does not meet the minimum compiler requirements to
1102*00b67f09SDavid van Moolenbroek	  for building BIND.  You need to install a ANSI C compiler and / or
1103*00b67f09SDavid van Moolenbroek	  teach configure how to find the ANSI C compiler.  The later can
1104*00b67f09SDavid van Moolenbroek	  be done by adjusting the PATH environment variable and / or
1105*00b67f09SDavid van Moolenbroek	  specifying the compiler via CC.
1106*00b67f09SDavid van Moolenbroek	</para>
1107*00b67f09SDavid van Moolenbroek	<informalexample>
1108*00b67f09SDavid van Moolenbroek	  <programlisting>./configure CC=&lt;compiler&gt; ...</programlisting>
1109*00b67f09SDavid van Moolenbroek	</informalexample>
1110*00b67f09SDavid van Moolenbroek      </answer>
1111*00b67f09SDavid van Moolenbroek    </qandaentry>
1112*00b67f09SDavid van Moolenbroek
1113*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- HPUX -->
1114*00b67f09SDavid van Moolenbroek
1115*00b67f09SDavid van Moolenbroek    <qandadiv><title>Linux</title>
1116*00b67f09SDavid van Moolenbroek
1117*00b67f09SDavid van Moolenbroek    <qandaentry>
1118*00b67f09SDavid van Moolenbroek      <question>
1119*00b67f09SDavid van Moolenbroek	<para>
1120*00b67f09SDavid van Moolenbroek	  Why do I get the following errors:
1121*00b67f09SDavid van Moolenbroek<programlisting>general: errno2result.c:109: unexpected error:
1122*00b67f09SDavid van Moolenbroekgeneral: unable to convert errno to isc_result: 14: Bad address
1123*00b67f09SDavid van Moolenbroekclient: UDP client handler shutting down due to fatal receive error: unexpected error</programlisting>
1124*00b67f09SDavid van Moolenbroek	</para>
1125*00b67f09SDavid van Moolenbroek      </question>
1126*00b67f09SDavid van Moolenbroek      <answer>
1127*00b67f09SDavid van Moolenbroek	<para>
1128*00b67f09SDavid van Moolenbroek	  This is the result of a Linux kernel bug.
1129*00b67f09SDavid van Moolenbroek	</para>
1130*00b67f09SDavid van Moolenbroek	<para>
1131*00b67f09SDavid van Moolenbroek	  See:
1132*00b67f09SDavid van Moolenbroek	  <ulink url="http://marc.theaimsgroup.com/?l=linux-netdev&amp;m=113081708031466&amp;w=2">&lt;http://marc.theaimsgroup.com/?l=linux-netdev&amp;m=113081708031466&amp;w=2&gt;</ulink>
1133*00b67f09SDavid van Moolenbroek	</para>
1134*00b67f09SDavid van Moolenbroek      </answer>
1135*00b67f09SDavid van Moolenbroek    </qandaentry>
1136*00b67f09SDavid van Moolenbroek
1137*00b67f09SDavid van Moolenbroek    <qandaentry>
1138*00b67f09SDavid van Moolenbroek      <question>
1139*00b67f09SDavid van Moolenbroek	<para>
1140*00b67f09SDavid van Moolenbroek	  Why does named lock up when it attempts to connect over IPSEC tunnels?
1141*00b67f09SDavid van Moolenbroek	</para>
1142*00b67f09SDavid van Moolenbroek      </question>
1143*00b67f09SDavid van Moolenbroek      <answer>
1144*00b67f09SDavid van Moolenbroek	<para>
1145*00b67f09SDavid van Moolenbroek	  This is due to a kernel bug where the fact that a socket is marked
1146*00b67f09SDavid van Moolenbroek	  non-blocking is ignored.  It is reported that setting
1147*00b67f09SDavid van Moolenbroek	  xfrm_larval_drop to 1 helps but this may have negative side effects.
1148*00b67f09SDavid van Moolenbroek	  See:
1149*00b67f09SDavid van Moolenbroek<ulink url="https://bugzilla.redhat.com/show_bug.cgi?id=427629">&lt;https://bugzilla.redhat.com/show_bug.cgi?id=427629&gt;</ulink>
1150*00b67f09SDavid van Moolenbroek	  and
1151*00b67f09SDavid van Moolenbroek<ulink url="http://lkml.org/lkml/2007/12/4/260">&lt;http://lkml.org/lkml/2007/12/4/260&gt;</ulink>.
1152*00b67f09SDavid van Moolenbroek	</para>
1153*00b67f09SDavid van Moolenbroek	<para>
1154*00b67f09SDavid van Moolenbroek	xfrm_larval_drop can be set to 1 by the following procedure:
1155*00b67f09SDavid van Moolenbroek<programlisting>
1156*00b67f09SDavid van Moolenbroekecho "1" &gt; proc/sys/net/core/xfrm_larval_drop</programlisting>
1157*00b67f09SDavid van Moolenbroek	</para>
1158*00b67f09SDavid van Moolenbroek      </answer>
1159*00b67f09SDavid van Moolenbroek    </qandaentry>
1160*00b67f09SDavid van Moolenbroek
1161*00b67f09SDavid van Moolenbroek    <qandaentry>
1162*00b67f09SDavid van Moolenbroek      <question>
1163*00b67f09SDavid van Moolenbroek	<para>
1164*00b67f09SDavid van Moolenbroek	  Why do I see 5 (or more) copies of named on Linux?
1165*00b67f09SDavid van Moolenbroek	</para>
1166*00b67f09SDavid van Moolenbroek      </question>
1167*00b67f09SDavid van Moolenbroek      <answer>
1168*00b67f09SDavid van Moolenbroek	<para>
1169*00b67f09SDavid van Moolenbroek	  Linux threads each show up as a process under ps.  The
1170*00b67f09SDavid van Moolenbroek	  approximate number of threads running is n+4, where n is
1171*00b67f09SDavid van Moolenbroek	  the number of CPUs.  Note that the amount of memory used
1172*00b67f09SDavid van Moolenbroek	  is not cumulative; if each process is using 10M of memory,
1173*00b67f09SDavid van Moolenbroek	  only a total of 10M is used.
1174*00b67f09SDavid van Moolenbroek	</para>
1175*00b67f09SDavid van Moolenbroek	<para>
1176*00b67f09SDavid van Moolenbroek	  Newer versions of Linux's ps command hide the individual threads
1177*00b67f09SDavid van Moolenbroek	  and require -L to display them.
1178*00b67f09SDavid van Moolenbroek	</para>
1179*00b67f09SDavid van Moolenbroek      </answer>
1180*00b67f09SDavid van Moolenbroek    </qandaentry>
1181*00b67f09SDavid van Moolenbroek
1182*00b67f09SDavid van Moolenbroek    <qandaentry>
1183*00b67f09SDavid van Moolenbroek      <question>
1184*00b67f09SDavid van Moolenbroek	<para>
1185*00b67f09SDavid van Moolenbroek	  Why does BIND 9 log <quote>permission denied</quote> errors accessing
1186*00b67f09SDavid van Moolenbroek	  its configuration files or zones on my Linux system even
1187*00b67f09SDavid van Moolenbroek	  though it is running as root?
1188*00b67f09SDavid van Moolenbroek	</para>
1189*00b67f09SDavid van Moolenbroek      </question>
1190*00b67f09SDavid van Moolenbroek      <answer>
1191*00b67f09SDavid van Moolenbroek	<para>
1192*00b67f09SDavid van Moolenbroek	  On Linux, BIND 9 drops most of its root privileges on
1193*00b67f09SDavid van Moolenbroek	  startup.  This including the privilege to open files owned
1194*00b67f09SDavid van Moolenbroek	  by other users.  Therefore, if the server is running as
1195*00b67f09SDavid van Moolenbroek	  root, the configuration files and zone files should also
1196*00b67f09SDavid van Moolenbroek	  be owned by root.
1197*00b67f09SDavid van Moolenbroek	</para>
1198*00b67f09SDavid van Moolenbroek      </answer>
1199*00b67f09SDavid van Moolenbroek    </qandaentry>
1200*00b67f09SDavid van Moolenbroek
1201*00b67f09SDavid van Moolenbroek    <qandaentry>
1202*00b67f09SDavid van Moolenbroek      <question>
1203*00b67f09SDavid van Moolenbroek	<para>
1204*00b67f09SDavid van Moolenbroek	  I get the error message <quote>named: capset failed: Operation
1205*00b67f09SDavid van Moolenbroek	  not permitted</quote> when starting named.
1206*00b67f09SDavid van Moolenbroek	</para>
1207*00b67f09SDavid van Moolenbroek      </question>
1208*00b67f09SDavid van Moolenbroek      <answer>
1209*00b67f09SDavid van Moolenbroek	<para>
1210*00b67f09SDavid van Moolenbroek	  The capability module, part of "Linux Security Modules/LSM",
1211*00b67f09SDavid van Moolenbroek	  has not been loaded into the kernel.  See insmod(8), modprobe(8).
1212*00b67f09SDavid van Moolenbroek	</para>
1213*00b67f09SDavid van Moolenbroek	<para>
1214*00b67f09SDavid van Moolenbroek	  The relevant modules can be loaded by running:
1215*00b67f09SDavid van Moolenbroek<programlisting>
1216*00b67f09SDavid van Moolenbroekmodprobe commoncap
1217*00b67f09SDavid van Moolenbroekmodprobe capability</programlisting>
1218*00b67f09SDavid van Moolenbroek	</para>
1219*00b67f09SDavid van Moolenbroek      </answer>
1220*00b67f09SDavid van Moolenbroek    </qandaentry>
1221*00b67f09SDavid van Moolenbroek
1222*00b67f09SDavid van Moolenbroek    <qandaentry>
1223*00b67f09SDavid van Moolenbroek      <question>
1224*00b67f09SDavid van Moolenbroek	<para>
1225*00b67f09SDavid van Moolenbroek	   I'm running BIND on Red Hat Enterprise Linux or Fedora Core -
1226*00b67f09SDavid van Moolenbroek	</para>
1227*00b67f09SDavid van Moolenbroek	<para>
1228*00b67f09SDavid van Moolenbroek	  Why can't named update slave zone database files?
1229*00b67f09SDavid van Moolenbroek	</para>
1230*00b67f09SDavid van Moolenbroek	<para>
1231*00b67f09SDavid van Moolenbroek	  Why can't named create DDNS journal files or update
1232*00b67f09SDavid van Moolenbroek	  the master zones from journals?
1233*00b67f09SDavid van Moolenbroek	</para>
1234*00b67f09SDavid van Moolenbroek	<para>
1235*00b67f09SDavid van Moolenbroek	  Why can't named create custom log files?
1236*00b67f09SDavid van Moolenbroek	</para>
1237*00b67f09SDavid van Moolenbroek      </question>
1238*00b67f09SDavid van Moolenbroek
1239*00b67f09SDavid van Moolenbroek      <answer>
1240*00b67f09SDavid van Moolenbroek	<para>
1241*00b67f09SDavid van Moolenbroek	  Red Hat Security Enhanced Linux (SELinux) policy security
1242*00b67f09SDavid van Moolenbroek	  protections :
1243*00b67f09SDavid van Moolenbroek	</para>
1244*00b67f09SDavid van Moolenbroek
1245*00b67f09SDavid van Moolenbroek	<para>
1246*00b67f09SDavid van Moolenbroek	   Red Hat have adopted the National Security Agency's
1247*00b67f09SDavid van Moolenbroek	   SELinux security policy (see <ulink
1248*00b67f09SDavid van Moolenbroek   url="http://www.nsa.gov/selinux">&lt;http://www.nsa.gov/selinux&gt;</ulink>)
1249*00b67f09SDavid van Moolenbroek	   and recommendations for BIND security , which are more
1250*00b67f09SDavid van Moolenbroek	   secure than running named in a chroot and make use of
1251*00b67f09SDavid van Moolenbroek	   the bind-chroot environment unnecessary .
1252*00b67f09SDavid van Moolenbroek	</para>
1253*00b67f09SDavid van Moolenbroek
1254*00b67f09SDavid van Moolenbroek	<para>
1255*00b67f09SDavid van Moolenbroek	  By default, named is not allowed by the SELinux policy
1256*00b67f09SDavid van Moolenbroek	  to write, create or delete any files EXCEPT in these
1257*00b67f09SDavid van Moolenbroek	  directories:
1258*00b67f09SDavid van Moolenbroek	  <informalexample>
1259*00b67f09SDavid van Moolenbroek	    <programlisting>
1260*00b67f09SDavid van Moolenbroek$ROOTDIR/var/named/slaves
1261*00b67f09SDavid van Moolenbroek$ROOTDIR/var/named/data
1262*00b67f09SDavid van Moolenbroek$ROOTDIR/var/tmp
1263*00b67f09SDavid van Moolenbroek	    </programlisting>
1264*00b67f09SDavid van Moolenbroek	  </informalexample>
1265*00b67f09SDavid van Moolenbroek	  where $ROOTDIR may be set in /etc/sysconfig/named if
1266*00b67f09SDavid van Moolenbroek	  bind-chroot is installed.
1267*00b67f09SDavid van Moolenbroek	</para>
1268*00b67f09SDavid van Moolenbroek
1269*00b67f09SDavid van Moolenbroek	<para>
1270*00b67f09SDavid van Moolenbroek	  The SELinux policy particularly does NOT allow named to modify
1271*00b67f09SDavid van Moolenbroek	  the $ROOTDIR/var/named directory, the default location for master
1272*00b67f09SDavid van Moolenbroek	  zone database files.
1273*00b67f09SDavid van Moolenbroek	</para>
1274*00b67f09SDavid van Moolenbroek
1275*00b67f09SDavid van Moolenbroek	<para>
1276*00b67f09SDavid van Moolenbroek	  SELinux policy overrules file access permissions - so
1277*00b67f09SDavid van Moolenbroek	  even if all the files under /var/named have ownership
1278*00b67f09SDavid van Moolenbroek	  named:named and mode rw-rw-r--, named will still not be
1279*00b67f09SDavid van Moolenbroek	  able to write or create files except in the directories
1280*00b67f09SDavid van Moolenbroek	  above, with SELinux in Enforcing mode.
1281*00b67f09SDavid van Moolenbroek	</para>
1282*00b67f09SDavid van Moolenbroek
1283*00b67f09SDavid van Moolenbroek	<para>
1284*00b67f09SDavid van Moolenbroek	  So, to allow named to update slave or DDNS zone files,
1285*00b67f09SDavid van Moolenbroek	  it is best to locate them in $ROOTDIR/var/named/slaves,
1286*00b67f09SDavid van Moolenbroek	  with named.conf zone statements such as:
1287*00b67f09SDavid van Moolenbroek	  <informalexample>
1288*00b67f09SDavid van Moolenbroek	    <programlisting>
1289*00b67f09SDavid van Moolenbroekzone "slave.zone." IN {
1290*00b67f09SDavid van Moolenbroek	type slave;
1291*00b67f09SDavid van Moolenbroek	file "slaves/slave.zone.db";
1292*00b67f09SDavid van Moolenbroek	...
1293*00b67f09SDavid van Moolenbroek};
1294*00b67f09SDavid van Moolenbroekzone "ddns.zone." IN  {
1295*00b67f09SDavid van Moolenbroek	type master;
1296*00b67f09SDavid van Moolenbroek	allow-updates {...};
1297*00b67f09SDavid van Moolenbroek	file "slaves/ddns.zone.db";
1298*00b67f09SDavid van Moolenbroek};
1299*00b67f09SDavid van Moolenbroek	    </programlisting>
1300*00b67f09SDavid van Moolenbroek	  </informalexample>
1301*00b67f09SDavid van Moolenbroek	</para>
1302*00b67f09SDavid van Moolenbroek
1303*00b67f09SDavid van Moolenbroek	<para>
1304*00b67f09SDavid van Moolenbroek	  To allow named to create its cache dump and statistics
1305*00b67f09SDavid van Moolenbroek	  files, for example, you could use named.conf options
1306*00b67f09SDavid van Moolenbroek	  statements such as:
1307*00b67f09SDavid van Moolenbroek	  <informalexample>
1308*00b67f09SDavid van Moolenbroek	    <programlisting>
1309*00b67f09SDavid van Moolenbroekoptions {
1310*00b67f09SDavid van Moolenbroek	...
1311*00b67f09SDavid van Moolenbroek	dump-file "/var/named/data/cache_dump.db";
1312*00b67f09SDavid van Moolenbroek	statistics-file "/var/named/data/named_stats.txt";
1313*00b67f09SDavid van Moolenbroek	...
1314*00b67f09SDavid van Moolenbroek};
1315*00b67f09SDavid van Moolenbroek	    </programlisting>
1316*00b67f09SDavid van Moolenbroek	  </informalexample>
1317*00b67f09SDavid van Moolenbroek	</para>
1318*00b67f09SDavid van Moolenbroek
1319*00b67f09SDavid van Moolenbroek	<para>
1320*00b67f09SDavid van Moolenbroek	  You can also tell SELinux to allow named to update any
1321*00b67f09SDavid van Moolenbroek	  zone database files, by setting the SELinux tunable boolean
1322*00b67f09SDavid van Moolenbroek	  parameter 'named_write_master_zones=1', using the
1323*00b67f09SDavid van Moolenbroek	  system-config-securitylevel GUI, using the 'setsebool'
1324*00b67f09SDavid van Moolenbroek	  command, or in /etc/selinux/targeted/booleans.
1325*00b67f09SDavid van Moolenbroek	</para>
1326*00b67f09SDavid van Moolenbroek
1327*00b67f09SDavid van Moolenbroek	<para>
1328*00b67f09SDavid van Moolenbroek	  You can disable SELinux protection for named entirely by
1329*00b67f09SDavid van Moolenbroek	  setting the 'named_disable_trans=1' SELinux tunable boolean
1330*00b67f09SDavid van Moolenbroek	  parameter.
1331*00b67f09SDavid van Moolenbroek	</para>
1332*00b67f09SDavid van Moolenbroek
1333*00b67f09SDavid van Moolenbroek	<para>
1334*00b67f09SDavid van Moolenbroek	  The SELinux named policy defines these SELinux contexts for named:
1335*00b67f09SDavid van Moolenbroek	  <informalexample>
1336*00b67f09SDavid van Moolenbroek	    <programlisting>
1337*00b67f09SDavid van Moolenbroeknamed_zone_t : for zone database files       - $ROOTDIR/var/named/*
1338*00b67f09SDavid van Moolenbroeknamed_conf_t : for named configuration files - $ROOTDIR/etc/{named,rndc}.*
1339*00b67f09SDavid van Moolenbroeknamed_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,data}}
1340*00b67f09SDavid van Moolenbroek	    </programlisting>
1341*00b67f09SDavid van Moolenbroek	  </informalexample>
1342*00b67f09SDavid van Moolenbroek	</para>
1343*00b67f09SDavid van Moolenbroek
1344*00b67f09SDavid van Moolenbroek	<para>
1345*00b67f09SDavid van Moolenbroek	  If you want to retain use of the SELinux policy for named,
1346*00b67f09SDavid van Moolenbroek	  and put named files in different locations, you can do
1347*00b67f09SDavid van Moolenbroek	  so by changing the context of the custom file locations
1348*00b67f09SDavid van Moolenbroek	  .
1349*00b67f09SDavid van Moolenbroek	</para>
1350*00b67f09SDavid van Moolenbroek
1351*00b67f09SDavid van Moolenbroek	<para>
1352*00b67f09SDavid van Moolenbroek	  To create a custom configuration file location, e.g.
1353*00b67f09SDavid van Moolenbroek	  '/root/named.conf', to use with the 'named -c' option,
1354*00b67f09SDavid van Moolenbroek	  do:
1355*00b67f09SDavid van Moolenbroek	  <informalexample>
1356*00b67f09SDavid van Moolenbroek	    <programlisting>
1357*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_conf_t /root/named.conf
1358*00b67f09SDavid van Moolenbroek	    </programlisting>
1359*00b67f09SDavid van Moolenbroek	  </informalexample>
1360*00b67f09SDavid van Moolenbroek	</para>
1361*00b67f09SDavid van Moolenbroek
1362*00b67f09SDavid van Moolenbroek	<para>
1363*00b67f09SDavid van Moolenbroek	  To create a custom modifiable named data location, e.g.
1364*00b67f09SDavid van Moolenbroek	  '/var/log/named' for a log file, do:
1365*00b67f09SDavid van Moolenbroek	  <informalexample>
1366*00b67f09SDavid van Moolenbroek	    <programlisting>
1367*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_cache_t /var/log/named
1368*00b67f09SDavid van Moolenbroek	    </programlisting>
1369*00b67f09SDavid van Moolenbroek	  </informalexample>
1370*00b67f09SDavid van Moolenbroek	</para>
1371*00b67f09SDavid van Moolenbroek
1372*00b67f09SDavid van Moolenbroek	<para>
1373*00b67f09SDavid van Moolenbroek   To create a custom zone file location, e.g. /root/zones/, do:
1374*00b67f09SDavid van Moolenbroek	  <informalexample>
1375*00b67f09SDavid van Moolenbroek	    <programlisting>
1376*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_zone_t /root/zones/{.,*}
1377*00b67f09SDavid van Moolenbroek	    </programlisting>
1378*00b67f09SDavid van Moolenbroek	  </informalexample>
1379*00b67f09SDavid van Moolenbroek	</para>
1380*00b67f09SDavid van Moolenbroek
1381*00b67f09SDavid van Moolenbroek	<para>
1382*00b67f09SDavid van Moolenbroek	  See these man-pages for more information : selinux(8),
1383*00b67f09SDavid van Moolenbroek	  named_selinux(8), chcon(1), setsebool(8)
1384*00b67f09SDavid van Moolenbroek	</para>
1385*00b67f09SDavid van Moolenbroek      </answer>
1386*00b67f09SDavid van Moolenbroek    </qandaentry>
1387*00b67f09SDavid van Moolenbroek
1388*00b67f09SDavid van Moolenbroek    <qandaentry>
1389*00b67f09SDavid van Moolenbroek      <question>
1390*00b67f09SDavid van Moolenbroek	<para>
1391*00b67f09SDavid van Moolenbroek	   I'm running BIND on Ubuntu -
1392*00b67f09SDavid van Moolenbroek	</para>
1393*00b67f09SDavid van Moolenbroek	<para>
1394*00b67f09SDavid van Moolenbroek	  Why can't named update slave zone database files?
1395*00b67f09SDavid van Moolenbroek	</para>
1396*00b67f09SDavid van Moolenbroek	<para>
1397*00b67f09SDavid van Moolenbroek	  Why can't named create DDNS journal files or update
1398*00b67f09SDavid van Moolenbroek	  the master zones from journals?
1399*00b67f09SDavid van Moolenbroek	</para>
1400*00b67f09SDavid van Moolenbroek	<para>
1401*00b67f09SDavid van Moolenbroek	  Why can't named create custom log files?
1402*00b67f09SDavid van Moolenbroek	</para>
1403*00b67f09SDavid van Moolenbroek      </question>
1404*00b67f09SDavid van Moolenbroek      <answer>
1405*00b67f09SDavid van Moolenbroek	<para>
1406*00b67f09SDavid van Moolenbroek	  Ubuntu uses AppArmor <ulink url="http://en.wikipedia.org/wiki/AppArmor">
1407*00b67f09SDavid van Moolenbroek          &lt;http://en.wikipedia.org/wiki/AppArmor&gt;</ulink> in
1408*00b67f09SDavid van Moolenbroek	  addition to normal file system permissions to protect the system.
1409*00b67f09SDavid van Moolenbroek	</para>
1410*00b67f09SDavid van Moolenbroek	<para>
1411*00b67f09SDavid van Moolenbroek	  Adjust the paths to use those specified in /etc/apparmor.d/usr.sbin.named
1412*00b67f09SDavid van Moolenbroek	  or adjust /etc/apparmor.d/usr.sbin.named to allow named to write at the
1413*00b67f09SDavid van Moolenbroek	  location specified in named.conf.
1414*00b67f09SDavid van Moolenbroek	</para>
1415*00b67f09SDavid van Moolenbroek      </answer>
1416*00b67f09SDavid van Moolenbroek    </qandaentry>
1417*00b67f09SDavid van Moolenbroek
1418*00b67f09SDavid van Moolenbroek    <qandaentry>
1419*00b67f09SDavid van Moolenbroek      <question>
1420*00b67f09SDavid van Moolenbroek	<para>
1421*00b67f09SDavid van Moolenbroek	  Listening on individual IPv6 interfaces does not work.
1422*00b67f09SDavid van Moolenbroek	</para>
1423*00b67f09SDavid van Moolenbroek      </question>
1424*00b67f09SDavid van Moolenbroek      <answer>
1425*00b67f09SDavid van Moolenbroek	<para>
1426*00b67f09SDavid van Moolenbroek	  This is usually due to "/proc/net/if_inet6" not being available
1427*00b67f09SDavid van Moolenbroek	  in the chroot file system.  Mount another instance of "proc"
1428*00b67f09SDavid van Moolenbroek	  in the chroot file system.
1429*00b67f09SDavid van Moolenbroek	</para>
1430*00b67f09SDavid van Moolenbroek	<para>
1431*00b67f09SDavid van Moolenbroek	  This can be be made permanent by adding a second instance to
1432*00b67f09SDavid van Moolenbroek	  /etc/fstab.
1433*00b67f09SDavid van Moolenbroek	  <informalexample>
1434*00b67f09SDavid van Moolenbroek	    <programlisting>
1435*00b67f09SDavid van Moolenbroekproc /proc           proc defaults 0 0
1436*00b67f09SDavid van Moolenbroekproc /var/named/proc proc defaults 0 0</programlisting>
1437*00b67f09SDavid van Moolenbroek	  </informalexample>
1438*00b67f09SDavid van Moolenbroek	</para>
1439*00b67f09SDavid van Moolenbroek      </answer>
1440*00b67f09SDavid van Moolenbroek    </qandaentry>
1441*00b67f09SDavid van Moolenbroek
1442*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Linux -->
1443*00b67f09SDavid van Moolenbroek
1444*00b67f09SDavid van Moolenbroek    <qandadiv><title>Windows</title>
1445*00b67f09SDavid van Moolenbroek
1446*00b67f09SDavid van Moolenbroek    <qandaentry>
1447*00b67f09SDavid van Moolenbroek      <question>
1448*00b67f09SDavid van Moolenbroek	<para>
1449*00b67f09SDavid van Moolenbroek	  Zone transfers from my BIND 9 master to my Windows 2000
1450*00b67f09SDavid van Moolenbroek	  slave fail.  Why?
1451*00b67f09SDavid van Moolenbroek	</para>
1452*00b67f09SDavid van Moolenbroek      </question>
1453*00b67f09SDavid van Moolenbroek      <answer>
1454*00b67f09SDavid van Moolenbroek	<para>
1455*00b67f09SDavid van Moolenbroek	  This may be caused by a bug in the Windows 2000 DNS server
1456*00b67f09SDavid van Moolenbroek	  where DNS messages larger than 16K are not handled properly.
1457*00b67f09SDavid van Moolenbroek	  This can be worked around by setting the option "transfer-format
1458*00b67f09SDavid van Moolenbroek	  one-answer;".  Also check whether your zone contains domain
1459*00b67f09SDavid van Moolenbroek	  names with embedded spaces or other special characters,
1460*00b67f09SDavid van Moolenbroek	  like "John\032Doe\213s\032Computer", since such names have
1461*00b67f09SDavid van Moolenbroek	  been known to cause Windows 2000 slaves to incorrectly
1462*00b67f09SDavid van Moolenbroek	  reject the zone.
1463*00b67f09SDavid van Moolenbroek	</para>
1464*00b67f09SDavid van Moolenbroek      </answer>
1465*00b67f09SDavid van Moolenbroek    </qandaentry>
1466*00b67f09SDavid van Moolenbroek
1467*00b67f09SDavid van Moolenbroek    <qandaentry>
1468*00b67f09SDavid van Moolenbroek      <question>
1469*00b67f09SDavid van Moolenbroek	<para>
1470*00b67f09SDavid van Moolenbroek	  I get <quote>Error 1067</quote> when starting named under Windows.
1471*00b67f09SDavid van Moolenbroek	</para>
1472*00b67f09SDavid van Moolenbroek      </question>
1473*00b67f09SDavid van Moolenbroek      <answer>
1474*00b67f09SDavid van Moolenbroek	<para>
1475*00b67f09SDavid van Moolenbroek	  This is the service manager saying that named exited.   You
1476*00b67f09SDavid van Moolenbroek	  need to examine the Application log in the EventViewer to
1477*00b67f09SDavid van Moolenbroek	  find out why.
1478*00b67f09SDavid van Moolenbroek	</para>
1479*00b67f09SDavid van Moolenbroek	<para>
1480*00b67f09SDavid van Moolenbroek	  Common causes are that you failed to create "named.conf"
1481*00b67f09SDavid van Moolenbroek	  (usually "C:\windows\dns\etc\named.conf") or failed to
1482*00b67f09SDavid van Moolenbroek	  specify the directory in named.conf.
1483*00b67f09SDavid van Moolenbroek	</para>
1484*00b67f09SDavid van Moolenbroek	<informalexample>
1485*00b67f09SDavid van Moolenbroek	  <programlisting>
1486*00b67f09SDavid van Moolenbroekoptions {
1487*00b67f09SDavid van Moolenbroek	Directory "C:\windows\dns\etc";
1488*00b67f09SDavid van Moolenbroek};</programlisting>
1489*00b67f09SDavid van Moolenbroek	</informalexample>
1490*00b67f09SDavid van Moolenbroek      </answer>
1491*00b67f09SDavid van Moolenbroek    </qandaentry>
1492*00b67f09SDavid van Moolenbroek
1493*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Windows -->
1494*00b67f09SDavid van Moolenbroek
1495*00b67f09SDavid van Moolenbroek    <qandadiv><title>FreeBSD</title>
1496*00b67f09SDavid van Moolenbroek
1497*00b67f09SDavid van Moolenbroek    <qandaentry>
1498*00b67f09SDavid van Moolenbroek      <question>
1499*00b67f09SDavid van Moolenbroek	<para>
1500*00b67f09SDavid van Moolenbroek	  I have FreeBSD 4.x and "rndc-confgen -a" just sits there.
1501*00b67f09SDavid van Moolenbroek	</para>
1502*00b67f09SDavid van Moolenbroek      </question>
1503*00b67f09SDavid van Moolenbroek      <answer>
1504*00b67f09SDavid van Moolenbroek	<para>
1505*00b67f09SDavid van Moolenbroek	  /dev/random is not configured.  Use rndcontrol(8) to tell
1506*00b67f09SDavid van Moolenbroek	  the kernel to use certain interrupts as a source of random
1507*00b67f09SDavid van Moolenbroek	  events.  You can make this permanent by setting rand_irqs
1508*00b67f09SDavid van Moolenbroek	  in /etc/rc.conf.
1509*00b67f09SDavid van Moolenbroek	</para>
1510*00b67f09SDavid van Moolenbroek	<informalexample>
1511*00b67f09SDavid van Moolenbroek	  <programlisting>
1512*00b67f09SDavid van Moolenbroekrand_irqs="3 14 15"</programlisting>
1513*00b67f09SDavid van Moolenbroek	</informalexample>
1514*00b67f09SDavid van Moolenbroek	<para>
1515*00b67f09SDavid van Moolenbroek	  See also
1516*00b67f09SDavid van Moolenbroek	  <ulink url="http://people.freebsd.org/~dougb/randomness.html">
1517*00b67f09SDavid van Moolenbroek	  &lt;http://people.freebsd.org/~dougb/randomness.html&gt;</ulink>.
1518*00b67f09SDavid van Moolenbroek	</para>
1519*00b67f09SDavid van Moolenbroek      </answer>
1520*00b67f09SDavid van Moolenbroek    </qandaentry>
1521*00b67f09SDavid van Moolenbroek
1522*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- FreeBSD -->
1523*00b67f09SDavid van Moolenbroek
1524*00b67f09SDavid van Moolenbroek    <qandadiv><title>Solaris</title>
1525*00b67f09SDavid van Moolenbroek
1526*00b67f09SDavid van Moolenbroek    <qandaentry>
1527*00b67f09SDavid van Moolenbroek      <question>
1528*00b67f09SDavid van Moolenbroek	<para>
1529*00b67f09SDavid van Moolenbroek	  How do I integrate BIND 9 and Solaris SMF
1530*00b67f09SDavid van Moolenbroek	</para>
1531*00b67f09SDavid van Moolenbroek      </question>
1532*00b67f09SDavid van Moolenbroek      <answer>
1533*00b67f09SDavid van Moolenbroek	<para>
1534*00b67f09SDavid van Moolenbroek	  Sun has a blog entry describing how to do this.
1535*00b67f09SDavid van Moolenbroek	</para>
1536*00b67f09SDavid van Moolenbroek	<para>
1537*00b67f09SDavid van Moolenbroek	  <ulink
1538*00b67f09SDavid van Moolenbroek	  url="http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris">
1539*00b67f09SDavid van Moolenbroek	 &lt;http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris&gt;
1540*00b67f09SDavid van Moolenbroek	  </ulink>
1541*00b67f09SDavid van Moolenbroek	</para>
1542*00b67f09SDavid van Moolenbroek      </answer>
1543*00b67f09SDavid van Moolenbroek    </qandaentry>
1544*00b67f09SDavid van Moolenbroek
1545*00b67f09SDavid van Moolenbroek    </qandadiv>
1546*00b67f09SDavid van Moolenbroek
1547*00b67f09SDavid van Moolenbroek    <qandadiv><title>Apple Mac OS X</title>
1548*00b67f09SDavid van Moolenbroek
1549*00b67f09SDavid van Moolenbroek    <qandaentry>
1550*00b67f09SDavid van Moolenbroek      <question>
1551*00b67f09SDavid van Moolenbroek	<para>
1552*00b67f09SDavid van Moolenbroek	  How do I run BIND 9 on Apple Mac OS X?
1553*00b67f09SDavid van Moolenbroek	</para>
1554*00b67f09SDavid van Moolenbroek      </question>
1555*00b67f09SDavid van Moolenbroek      <answer>
1556*00b67f09SDavid van Moolenbroek	<para>
1557*00b67f09SDavid van Moolenbroek	 If you run Tiger(Mac OS 10.4) or later then this is all you need to do:
1558*00b67f09SDavid van Moolenbroek	</para>
1559*00b67f09SDavid van Moolenbroek	<informalexample>
1560*00b67f09SDavid van Moolenbroek	  <programlisting>
1561*00b67f09SDavid van Moolenbroek% sudo rndc-confgen  > /etc/rndc.conf</programlisting>
1562*00b67f09SDavid van Moolenbroek	</informalexample>
1563*00b67f09SDavid van Moolenbroek	<para>
1564*00b67f09SDavid van Moolenbroek	  Copy the key statement from /etc/rndc.conf into /etc/rndc.key, e.g.:
1565*00b67f09SDavid van Moolenbroek	</para>
1566*00b67f09SDavid van Moolenbroek	<informalexample>
1567*00b67f09SDavid van Moolenbroek	  <programlisting>
1568*00b67f09SDavid van Moolenbroekkey "rndc-key" {
1569*00b67f09SDavid van Moolenbroek	algorithm hmac-sha256;
1570*00b67f09SDavid van Moolenbroek	secret "uvceheVuqf17ZwIcTydddw==";
1571*00b67f09SDavid van Moolenbroek};</programlisting>
1572*00b67f09SDavid van Moolenbroek	</informalexample>
1573*00b67f09SDavid van Moolenbroek	<para>
1574*00b67f09SDavid van Moolenbroek	  Then start the relevant service:
1575*00b67f09SDavid van Moolenbroek	</para>
1576*00b67f09SDavid van Moolenbroek	<informalexample>
1577*00b67f09SDavid van Moolenbroek	  <programlisting>
1578*00b67f09SDavid van Moolenbroek% sudo service org.isc.named start</programlisting>
1579*00b67f09SDavid van Moolenbroek	</informalexample>
1580*00b67f09SDavid van Moolenbroek	<para>
1581*00b67f09SDavid van Moolenbroek	  This is persistent upon a reboot, so you will have to do it only once.
1582*00b67f09SDavid van Moolenbroek	</para>
1583*00b67f09SDavid van Moolenbroek      </answer>
1584*00b67f09SDavid van Moolenbroek
1585*00b67f09SDavid van Moolenbroek      <answer>
1586*00b67f09SDavid van Moolenbroek	<para>
1587*00b67f09SDavid van Moolenbroek	 Alternatively you can just generate /etc/rndc.key by running:
1588*00b67f09SDavid van Moolenbroek	</para>
1589*00b67f09SDavid van Moolenbroek	<informalexample>
1590*00b67f09SDavid van Moolenbroek	  <programlisting>
1591*00b67f09SDavid van Moolenbroek% sudo rndc-confgen -a</programlisting>
1592*00b67f09SDavid van Moolenbroek	</informalexample>
1593*00b67f09SDavid van Moolenbroek	<para>
1594*00b67f09SDavid van Moolenbroek	  Then start the relevant service:
1595*00b67f09SDavid van Moolenbroek	</para>
1596*00b67f09SDavid van Moolenbroek	<informalexample>
1597*00b67f09SDavid van Moolenbroek	  <programlisting>
1598*00b67f09SDavid van Moolenbroek% sudo service org.isc.named start</programlisting>
1599*00b67f09SDavid van Moolenbroek	</informalexample>
1600*00b67f09SDavid van Moolenbroek	<para>
1601*00b67f09SDavid van Moolenbroek	  Named will look for /etc/rndc.key when it starts if it
1602*00b67f09SDavid van Moolenbroek	  doesn't have a controls section or the existing controls are
1603*00b67f09SDavid van Moolenbroek	  missing keys sub-clauses.  This is persistent upon a
1604*00b67f09SDavid van Moolenbroek	  reboot, so you will have to do it only once.
1605*00b67f09SDavid van Moolenbroek	</para>
1606*00b67f09SDavid van Moolenbroek      </answer>
1607*00b67f09SDavid van Moolenbroek    </qandaentry>
1608*00b67f09SDavid van Moolenbroek
1609*00b67f09SDavid van Moolenbroek    </qandadiv>
1610*00b67f09SDavid van Moolenbroek
1611*00b67f09SDavid van Moolenbroek    </qandadiv> <!-- Operating-System Specific Questions -->
1612*00b67f09SDavid van Moolenbroek
1613*00b67f09SDavid van Moolenbroek  </qandaset>
1614*00b67f09SDavid van Moolenbroek</article>
1615