1577 lines
44 KiB
XML
1577 lines
44 KiB
XML
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
|
|
<!--
|
|
- Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
|
|
- Copyright (C) 2000-2003 Internet Software Consortium.
|
|
-
|
|
- Permission to use, copy, modify, and/or distribute this software for any
|
|
- purpose with or without fee is hereby granted, provided that the above
|
|
- copyright notice and this permission notice appear in all copies.
|
|
-
|
|
- THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
|
|
- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
|
|
- AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
|
|
- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
|
|
- LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
|
|
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
|
- PERFORMANCE OF THIS SOFTWARE.
|
|
-->
|
|
|
|
<!-- $Id: FAQ.xml,v 1.4.4.24 2008/09/10 01:32:25 tbox Exp $ -->
|
|
|
|
<article class="faq">
|
|
<title>Frequently Asked Questions about BIND 9</title>
|
|
<articleinfo>
|
|
<copyright>
|
|
<year>2004</year>
|
|
<year>2005</year>
|
|
<year>2006</year>
|
|
<year>2007</year>
|
|
<year>2008</year>
|
|
<holder>Internet Systems Consortium, Inc. ("ISC")</holder>
|
|
</copyright>
|
|
<copyright>
|
|
<year>2000</year>
|
|
<year>2001</year>
|
|
<year>2002</year>
|
|
<year>2003</year>
|
|
<holder>Internet Software Consortium.</holder>
|
|
</copyright>
|
|
</articleinfo>
|
|
<qandaset defaultlabel='qanda'>
|
|
|
|
<qandadiv><title>Compilation and Installation Questions</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I'm trying to compile BIND 9, and "make" is failing due to
|
|
files not being found. Why?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Using a parallel or distributed "make" to build BIND 9 is
|
|
not supported, and doesn't work. If you are using one of
|
|
these, use normal make or gmake instead.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Isn't "make install" supposed to generate a default named.conf?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Short Answer: No.
|
|
</para>
|
|
<para>
|
|
Long Answer: There really isn't a default configuration which fits
|
|
any site perfectly. There are lots of decisions that need to
|
|
be made and there is no consensus on what the defaults should be.
|
|
For example FreeBSD uses /etc/namedb as the location where the
|
|
configuration files for named are stored. Others use /var/named.
|
|
</para>
|
|
<para>
|
|
What addresses to listen on? For a laptop on the move a lot
|
|
you may only want to listen on the loop back interfaces.
|
|
</para>
|
|
<para>
|
|
Who do you offer recursive service to? Is there are firewall
|
|
to consider? If so is it stateless or stateful. Are you
|
|
directly on the Internet? Are you on a private network? Are
|
|
you on a NAT'd network? The answers
|
|
to all these questions change how you configure even a
|
|
caching name server.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- Compilation and Installation Questions -->
|
|
|
|
<qandadiv><title>Configuration and Setup Questions</title>
|
|
|
|
<qandaentry>
|
|
<!-- configuration, log -->
|
|
<question>
|
|
<para>
|
|
Why does named log the warning message <quote>no TTL specified -
|
|
using SOA MINTTL instead</quote>?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Your zone file is illegal according to RFC1035. It must either
|
|
have a line like:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
$TTL 86400</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
at the beginning, or the first record in it must have a TTL field,
|
|
like the "84600" in this example:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
example.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<!-- configuration -->
|
|
<question>
|
|
<para>
|
|
Why do I get errors like <quote>dns_zone_load: zone foo/IN: loading
|
|
master file bar: ran out of space</quote>?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is often caused by TXT records with missing close
|
|
quotes. Check that all TXT records containing quoted strings
|
|
have both open and close quotes.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<!-- security -->
|
|
<question>
|
|
<para>
|
|
How do I restrict people from looking up the server version?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Put a "version" option containing something other than the
|
|
real version in the "options" section of named.conf. Note
|
|
doing this will not prevent attacks and may impede people
|
|
trying to diagnose problems with your server. Also it is
|
|
possible to "fingerprint" nameservers to determine their
|
|
version.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<!-- security -->
|
|
<question>
|
|
<para>
|
|
How do I restrict only remote users from looking up the
|
|
server version?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
The following view statement will intercept lookups as the
|
|
internal view that holds the version information will be
|
|
matched last. The caveats of the previous answer still
|
|
apply, of course.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
view "chaos" chaos {
|
|
match-clients { <those to be refused>; };
|
|
allow-query { none; };
|
|
zone "." {
|
|
type hint;
|
|
file "/dev/null"; // or any empty file
|
|
};
|
|
};</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<!-- configuration -->
|
|
<question>
|
|
<para>
|
|
What do <quote>no source of entropy found</quote> or <quote>could not
|
|
open entropy source foo</quote> mean?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
The server requires a source of entropy to perform certain
|
|
operations, mostly DNSSEC related. These messages indicate
|
|
that you have no source of entropy. On systems with
|
|
/dev/random or an equivalent, it is used by default. A
|
|
source of entropy can also be defined using the random-device
|
|
option in named.conf.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<!-- configuration -->
|
|
<question>
|
|
<para>
|
|
I'm trying to use TSIG to authenticate dynamic updates or
|
|
zone transfers. I'm sure I have the keys set up correctly,
|
|
but the server is rejecting the TSIG. Why?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This may be a clock skew problem. Check that the the clocks
|
|
on the client and server are properly synchronised (e.g.,
|
|
using ntp).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I see a log message like the following. Why?
|
|
</para>
|
|
<para>
|
|
couldn't open pid file '/var/run/named.pid': Permission denied
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You are most likely running named as a non-root user, and
|
|
that user does not have permission to write in /var/run.
|
|
The common ways of fixing this are to create a /var/run/named
|
|
directory owned by the named user and set pid-file to
|
|
"/var/run/named/named.pid", or set pid-file to "named.pid",
|
|
which will put the file in the directory specified by the
|
|
directory option (which, in this case, must be writable by
|
|
the named user).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I can query the nameserver from the nameserver but not from other
|
|
machines. Why?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is usually the result of the firewall configuration stopping
|
|
the queries and / or the replies.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How can I make a server a slave for both an internal and
|
|
an external view at the same time? When I tried, both views
|
|
on the slave were transferred from the same view on the master.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You will need to give the master and slave multiple IP
|
|
addresses and use those to make sure you reach the correct
|
|
view on the other machine.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
Master: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
|
|
internal:
|
|
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
|
|
notify-source 10.0.1.1;
|
|
transfer-source 10.0.1.1;
|
|
query-source address 10.0.1.1;
|
|
external:
|
|
match-clients { any; };
|
|
recursion no; // don't offer recursion to the world
|
|
notify-source 10.0.1.2;
|
|
transfer-source 10.0.1.2;
|
|
query-source address 10.0.1.2;
|
|
|
|
Slave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
|
|
internal:
|
|
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
|
|
notify-source 10.0.1.3;
|
|
transfer-source 10.0.1.3;
|
|
query-source address 10.0.1.3;
|
|
external:
|
|
match-clients { any; };
|
|
recursion no; // don't offer recursion to the world
|
|
notify-source 10.0.1.4;
|
|
transfer-source 10.0.1.4;
|
|
query-source address 10.0.1.4;</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
You put the external address on the alias so that all the other
|
|
dns clients on these boxes see the internal view by default.
|
|
</para>
|
|
</answer>
|
|
<answer>
|
|
<para>
|
|
BIND 9.3 and later: Use TSIG to select the appropriate view.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
Master 10.0.1.1:
|
|
key "external" {
|
|
algorithm hmac-md5;
|
|
secret "xxxxxxxx";
|
|
};
|
|
view "internal" {
|
|
match-clients { !key external; 10.0.1/24; };
|
|
...
|
|
};
|
|
view "external" {
|
|
match-clients { key external; any; };
|
|
server 10.0.1.2 { keys external; };
|
|
recursion no;
|
|
...
|
|
};
|
|
|
|
Slave 10.0.1.2:
|
|
key "external" {
|
|
algorithm hmac-md5;
|
|
secret "xxxxxxxx";
|
|
};
|
|
view "internal" {
|
|
match-clients { !key external; 10.0.1/24; };
|
|
...
|
|
};
|
|
view "external" {
|
|
match-clients { key external; any; };
|
|
server 10.0.1.1 { keys external; };
|
|
recursion no;
|
|
...
|
|
};</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get error messages like <quote>multiple RRs of singleton type</quote>
|
|
and <quote>CNAME and other data</quote> when transferring a zone. What
|
|
does this mean?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
These indicate a malformed master zone. You can identify
|
|
the exact records involved by transferring the zone using
|
|
dig then running named-checkzone on it.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
dig axfr example.com @master-server > tmp
|
|
named-checkzone example.com tmp</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
A CNAME record cannot exist with the same name as another record
|
|
except for the DNSSEC records which prove its existence (NSEC).
|
|
</para>
|
|
<para>
|
|
RFC 1034, Section 3.6.2: <quote>If a CNAME RR is present at a node,
|
|
no other data should be present; this ensures that the data for a
|
|
canonical name and its aliases cannot be different. This rule also
|
|
insures that a cached CNAME can be used without checking with an
|
|
authoritative server for other RR types.</quote>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get error messages like <quote>named.conf:99: unexpected end
|
|
of input</quote> where 99 is the last line of named.conf.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
There are unbalanced quotes in named.conf.
|
|
</para>
|
|
</answer>
|
|
<answer>
|
|
<para>
|
|
Some text editors (notepad and wordpad) fail to put a line
|
|
title indication (e.g. CR/LF) on the last line of a
|
|
text file. This can be fixed by "adding" a blank line to
|
|
the end of the file. Named expects to see EOF immediately
|
|
after EOL and treats text files where this is not met as
|
|
truncated.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How do I share a dynamic zone between multiple views?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You choose one view to be master and the second a slave and
|
|
transfer the zone between views.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
Master 10.0.1.1:
|
|
key "external" {
|
|
algorithm hmac-md5;
|
|
secret "xxxxxxxx";
|
|
};
|
|
|
|
key "mykey" {
|
|
algorithm hmac-md5;
|
|
secret "yyyyyyyy";
|
|
};
|
|
|
|
view "internal" {
|
|
match-clients { !key external; 10.0.1/24; };
|
|
server 10.0.1.1 {
|
|
/* Deliver notify messages to external view. */
|
|
keys { external; };
|
|
};
|
|
zone "example.com" {
|
|
type master;
|
|
file "internal/example.db";
|
|
allow-update { key mykey; };
|
|
notify-also { 10.0.1.1; };
|
|
};
|
|
};
|
|
|
|
view "external" {
|
|
match-clients { key external; any; };
|
|
zone "example.com" {
|
|
type slave;
|
|
file "external/example.db";
|
|
masters { 10.0.1.1; };
|
|
transfer-source { 10.0.1.1; };
|
|
// allow-update-forwarding { any; };
|
|
// allow-notify { ... };
|
|
};
|
|
};</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get a error message like <quote>zone wireless.ietf56.ietf.org/IN:
|
|
loading master file primaries/wireless.ietf56.ietf.org: no
|
|
owner</quote>.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This error is produced when a line in the master file
|
|
contains leading white space (tab/space) but the is no
|
|
current record owner name to inherit the name from. Usually
|
|
this is the result of putting white space before a comment,
|
|
forgetting the "@" for the SOA record, or indenting the master
|
|
file.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why are my logs in GMT (UTC).
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You are running chrooted (-t) and have not supplied local timezone
|
|
information in the chroot area.
|
|
</para>
|
|
<simplelist>
|
|
<member>FreeBSD: /etc/localtime</member>
|
|
<member>Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo</member>
|
|
<member>OSF: /etc/zoneinfo/localtime</member>
|
|
</simplelist>
|
|
<para>
|
|
See also tzset(3) and zic(8).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get <quote>rndc: connect failed: connection refused</quote> when
|
|
I try to run rndc.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is usually a configuration error.
|
|
</para>
|
|
<para>
|
|
First ensure that named is running and no errors are being
|
|
reported at startup (/var/log/messages or equivalent).
|
|
Running "named -g <usual arguments>" from a title
|
|
can help at this point.
|
|
</para>
|
|
<para>
|
|
Secondly ensure that named is configured to use rndc either
|
|
by "rndc-confgen -a", rndc-confgen or manually. The
|
|
Administrators Reference manual has details on how to do
|
|
this.
|
|
</para>
|
|
<para>
|
|
Old versions of rndc-confgen used localhost rather than
|
|
127.0.0.1 in /etc/rndc.conf for the default server. Update
|
|
/etc/rndc.conf if necessary so that the default server
|
|
listed in /etc/rndc.conf matches the addresses used in
|
|
named.conf. "localhost" has two address (127.0.0.1 and
|
|
::1).
|
|
</para>
|
|
<para>
|
|
If you use "rndc-confgen -a" and named is running with -t or -u
|
|
ensure that /etc/rndc.conf has the correct ownership and that
|
|
a copy is in the chroot area. You can do this by re-running
|
|
"rndc-confgen -a" with appropriate -t and -u arguments.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get <quote>transfer of 'example.net/IN' from 192.168.4.12#53:
|
|
failed while receiving responses: permission denied</quote> error
|
|
messages.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
These indicate a filesystem permission error preventing
|
|
named creating / renaming the temporary file. These will
|
|
usually also have other associated error messages like
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
Named needs write permission on the directory containing
|
|
the file. Named writes the new cache file to a temporary
|
|
file then renames it to the name specified in named.conf
|
|
to ensure that the contents are always complete. This is
|
|
to prevent named loading a partial zone in the event of
|
|
power failure or similar interrupting the write of the
|
|
master file.
|
|
</para>
|
|
<para>
|
|
Note file names are relative to the directory specified in
|
|
options and any chroot directory ([<chroot
|
|
dir>/][<options dir>]).
|
|
</para>
|
|
<informalexample>
|
|
<para>
|
|
If named is invoked as "named -t /chroot/DNS" with
|
|
the following named.conf then "/chroot/DNS/var/named/sl"
|
|
needs to be writable by the user named is running as.
|
|
</para>
|
|
<programlisting>
|
|
options {
|
|
directory "/var/named";
|
|
};
|
|
|
|
zone "example.net" {
|
|
type slave;
|
|
file "sl/example.net";
|
|
masters { 192.168.4.12; };
|
|
};</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I want to forward all DNS queries from my caching nameserver to
|
|
another server. But there are some domains which have to be
|
|
served locally, via rbldnsd.
|
|
</para>
|
|
<para>
|
|
How do I achieve this ?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<programlisting>
|
|
options {
|
|
forward only;
|
|
forwarders { <ip.of.primary.nameserver>; };
|
|
};
|
|
|
|
zone "sbl-xbl.spamhaus.org" {
|
|
type forward; forward only;
|
|
forwarders { <ip.of.rbldns.server> port 530; };
|
|
};
|
|
|
|
zone "list.dsbl.org" {
|
|
type forward; forward only;
|
|
forwarders { <ip.of.rbldns.server> port 530; };
|
|
};
|
|
</programlisting>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Can you help me understand how BIND 9 uses memory to store
|
|
DNS zones?
|
|
</para>
|
|
<para>
|
|
Some times it seems to take several times the amount of
|
|
memory it needs to store the zone.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
When reloading a zone named my have multiple copies of
|
|
the zone in memory at one time. The zone it is serving
|
|
and the one it is loading. If reloads are ultra fast it
|
|
can have more still.
|
|
</para>
|
|
<para>
|
|
e.g. Ones that are transferring out, the one that it is
|
|
serving and the one that is loading.
|
|
</para>
|
|
<para>
|
|
BIND 8 destroyed the zone before loading and also killed
|
|
off outgoing transfers of the zone.
|
|
</para>
|
|
<para>
|
|
The new strategy allows slaves to get copies of the new
|
|
zone regardless of how often the master is loaded compared
|
|
to the transfer time. The slave might skip some intermediate
|
|
versions but the transfers will complete and it will keep
|
|
reasonably in sync with the master.
|
|
</para>
|
|
<para>
|
|
The new strategy also allows the master to recover from
|
|
syntax and other errors in the master file as it still
|
|
has an in-core copy of the old contents.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I want to use IPv6 locally but I don't have a external IPv6
|
|
connection. External lookups are slow.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You can use server clauses to stop named making external lookups
|
|
over IPv6.
|
|
</para>
|
|
<programlisting>
|
|
server fd81:ec6c:bd62::/48 { bogus no; }; // site ULA prefix
|
|
server ::/0 { bogus yes; };
|
|
</programlisting>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- Configuration and Setup Questions -->
|
|
|
|
<qandadiv><title>Operations Questions</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How to change the nameservers for a zone?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Step 1: Ensure all nameservers, new and old, are serving the
|
|
same zone content.
|
|
</para>
|
|
<para>
|
|
Step 2: Work out the maximum TTL of the NS RRset in the parent and child
|
|
zones. This is the time it will take caches to be clear of a
|
|
particular version of the NS RRset.
|
|
If you are just removing nameservers you can skip to Step 6.
|
|
</para>
|
|
<para>
|
|
Step 3: Add new nameservers to the NS RRset for the zone and
|
|
wait until all the servers for the zone are answering with this
|
|
new NS RRset.
|
|
</para>
|
|
<para>
|
|
Step 4: Inform the parent zone of the new NS RRset then wait for all the
|
|
parent servers to be answering with the new NS RRset.
|
|
</para>
|
|
<para>
|
|
Step 5: Wait for cache to be clear of the old NS RRset.
|
|
See Step 2 for how long.
|
|
If you are just adding nameservers you are done.
|
|
</para>
|
|
<para>
|
|
Step 6: Remove any old nameservers from the zones NS RRset and
|
|
wait for all the servers for the zone to be serving the new NS RRset.
|
|
</para>
|
|
<para>
|
|
Step 7: Inform the parent zone of the new NS RRset then wait for all the
|
|
parent servers to be answering with the new NS RRset.
|
|
</para>
|
|
<para>
|
|
Step 8: Wait for cache to be clear of the old NS RRset.
|
|
See Step 2 for how long.
|
|
</para>
|
|
<para>
|
|
Step 9: Turn off the old nameservers or remove the zone entry from
|
|
the configuration of the old nameservers.
|
|
</para>
|
|
<para>
|
|
Step 10: Increment the serial number and wait for the change to
|
|
be visible in all nameservers for the zone. This ensures that
|
|
zone transfers are still working after the old servers are
|
|
decommissioned.
|
|
</para>
|
|
<para>
|
|
Note: the above procedure is designed to be transparent
|
|
to dns clients. Decommissioning the old servers too early
|
|
will result in some clients not being able to look up
|
|
answers in the zone.
|
|
</para>
|
|
<para>
|
|
Note: while it is possible to run the addition and removal
|
|
stages together it is not recommended.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- Operations Questions -->
|
|
|
|
<qandadiv><title>General Questions</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I keep getting log messages like the following. Why?
|
|
</para>
|
|
<para>
|
|
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone
|
|
'example.com/IN': update failed: 'RRset exists (value
|
|
dependent)' prerequisite not satisfied (NXRRSET)
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
DNS updates allow the update request to test to see if
|
|
certain conditions are met prior to proceeding with the
|
|
update. The message above is saying that conditions were
|
|
not met and the update is not proceeding. See doc/rfc/rfc2136.txt
|
|
for more details on prerequisites.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I keep getting log messages like the following. Why?
|
|
</para>
|
|
<para>
|
|
Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Someone is trying to update your DNS data using the RFC2136
|
|
Dynamic Update protocol. Windows 2000 machines have a habit
|
|
of sending dynamic update requests to DNS servers without
|
|
being specifically configured to do so. If the update
|
|
requests are coming from a Windows 2000 machine, see
|
|
<ulink
|
|
url="http://support.microsoft.com/support/kb/articles/q246/8/04.asp">
|
|
<http://support.microsoft.com/support/kb/articles/q246/8/04.asp></ulink>
|
|
for information about how to turn them off.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
When I do a "dig . ns", many of the A records for the root
|
|
servers are missing. Why?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is normal and harmless. It is a somewhat confusing
|
|
side effect of the way BIND 9 does RFC2181 trust ranking
|
|
and of the efforts BIND 9 makes to avoid promoting glue
|
|
into answers.
|
|
</para>
|
|
<para>
|
|
When BIND 9 first starts up and primes its cache, it receives
|
|
the root server addresses as additional data in an authoritative
|
|
response from a root server, and these records are eligible
|
|
for inclusion as additional data in responses. Subsequently
|
|
it receives a subset of the root server addresses as
|
|
additional data in a non-authoritative (referral) response
|
|
from a root server. This causes the addresses to now be
|
|
considered non-authoritative (glue) data, which is not
|
|
eligible for inclusion in responses.
|
|
</para>
|
|
<para>
|
|
The server does have a complete set of root server addresses
|
|
cached at all times, it just may not include all of them
|
|
as additional data, depending on whether they were last
|
|
received as answers or as glue. You can always look up the
|
|
addresses with explicit queries like "dig a.root-servers.net A".
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why don't my zones reload when I do an "rndc reload" or SIGHUP?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
A zone can be updated either by editing zone files and
|
|
reloading the server or by dynamic update, but not both.
|
|
If you have enabled dynamic update for a zone using the
|
|
"allow-update" option, you are not supposed to edit the
|
|
zone file by hand, and the server will not attempt to reload
|
|
it.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why is named listening on UDP port other than 53?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Named uses a system selected port to make queries of other
|
|
nameservers. This behaviour can be overridden by using
|
|
query-source to lock down the port and/or address. See
|
|
also notify-source and transfer-source.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get warning messages like <quote>zone example.com/IN: refresh:
|
|
failure trying master 1.2.3.4#53: timed out</quote>.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Check that you can make UDP queries from the slave to the master
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
dig +norec example.com soa @1.2.3.4</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
You could be generating queries faster than the slave can
|
|
cope with. Lower the serial query rate.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
serial-query-rate 5; // default 20</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I don't get RRSIG's returned when I use "dig +dnssec".
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You need to ensure DNSSEC is enabled (dnssec-enable yes;).
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Can a NS record refer to a CNAME.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
No. The rules for glue (copies of the *address* records
|
|
in the parent zones) and additional section processing do
|
|
not allow it to work.
|
|
</para>
|
|
<para>
|
|
You would have to add both the CNAME and address records
|
|
(A/AAAA) as glue to the parent zone and have CNAMEs be
|
|
followed when doing additional section processing to make
|
|
it work. No nameserver implementation supports either of
|
|
these requirements.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
What does <quote>RFC 1918 response from Internet for
|
|
0.0.0.10.IN-ADDR.ARPA</quote> mean?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
If the IN-ADDR.ARPA name covered refers to a internal address
|
|
space you are using then you have failed to follow RFC 1918
|
|
usage rules and are leaking queries to the Internet. You
|
|
should establish your own zones for these addresses to prevent
|
|
you querying the Internet's name servers for these addresses.
|
|
Please see <ulink url="http://as112.net/"><http://as112.net/></ulink>
|
|
for details of the problems you are causing and the counter
|
|
measures that have had to be deployed.
|
|
</para>
|
|
<para>
|
|
If you are not using these private addresses then a client
|
|
has queried for them. You can just ignore the messages,
|
|
get the offending client to stop sending you these messages
|
|
as they are most probably leaking them or setup your own zones
|
|
empty zones to serve answers to these queries.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
zone "10.IN-ADDR.ARPA" {
|
|
type master;
|
|
file "empty";
|
|
};
|
|
|
|
zone "16.172.IN-ADDR.ARPA" {
|
|
type master;
|
|
file "empty";
|
|
};
|
|
|
|
...
|
|
|
|
zone "31.172.IN-ADDR.ARPA" {
|
|
type master;
|
|
file "empty";
|
|
};
|
|
|
|
zone "168.192.IN-ADDR.ARPA" {
|
|
type master;
|
|
file "empty";
|
|
};
|
|
|
|
empty:
|
|
@ 10800 IN SOA <name-of-server>. <contact-email>. (
|
|
1 3600 1200 604800 10800 )
|
|
@ 10800 IN NS <name-of-server>.</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
<note>
|
|
Future versions of named are likely to do this automatically.
|
|
</note>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Will named be affected by the 2007 changes to daylight savings
|
|
rules in the US.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
No, so long as the machines internal clock (as reported
|
|
by "date -u") remains at UTC. The only visible change
|
|
if you fail to upgrade your OS, if you are in a affected
|
|
area, will be that log messages will be a hour out during
|
|
the period where the old rules do not match the new rules.
|
|
</para>
|
|
<para>
|
|
For most OS's this change just means that you need to
|
|
update the conversion rules from UTC to local time.
|
|
Normally this involves updating a file in /etc (which
|
|
sets the default timezone for the machine) and possibly
|
|
a directory which has all the conversion rules for the
|
|
world (e.g. /usr/share/zoneinfo). When updating the OS
|
|
do not forget to update any chroot areas as well.
|
|
See your OS's documentation for more details.
|
|
</para>
|
|
<para>
|
|
The local timezone conversion rules can also be done on
|
|
a individual basis by setting the TZ environment variable
|
|
appropriately. See your OS's documentation for more
|
|
details.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Is there a bugzilla (or other tool) database that mere
|
|
mortals can have (read-only) access to for bind?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
No. The BIND 9 bug database is kept closed for a number
|
|
of reasons. These include, but are not limited to, that
|
|
the database contains proprietory information from people
|
|
reporting bugs. The database has in the past and may in
|
|
future contain unfixed bugs which are capable of bringing
|
|
down most of the Internet's DNS infrastructure.
|
|
</para>
|
|
<para>
|
|
The release pages for each version contain up to date
|
|
lists of bugs that have been fixed post release. That
|
|
is as close as we can get to providing a bug database.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why do queries for NSEC3 records fail to return the NSEC3 record?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
NSEC3 records are strictly meta data and can only be
|
|
returned in the authority section. This is done so that
|
|
signing the zone using NSEC3 records does not bring names
|
|
into existance that do not exist in the unsigned version
|
|
of the zone.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- General Questions -->
|
|
|
|
<qandadiv><title>Operating-System Specific Questions</title>
|
|
|
|
<qandadiv><title>HPUX</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>I get the following error trying to configure BIND:
|
|
<programlisting>checking if unistd.h or sys/types.h defines fd_set... no
|
|
configure: error: need either working unistd.h or sys/select.h</programlisting>
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
You have attempted to configure BIND with the bundled C compiler.
|
|
This compiler does not meet the minimum compiler requirements to
|
|
for building BIND. You need to install a ANSI C compiler and / or
|
|
teach configure how to find the ANSI C compiler. The later can
|
|
be done by adjusting the PATH environment variable and / or
|
|
specifying the compiler via CC.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>./configure CC=<compiler> ...</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- HPUX -->
|
|
|
|
<qandadiv><title>Linux</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why do I get the following errors:
|
|
<programlisting>general: errno2result.c:109: unexpected error:
|
|
general: unable to convert errno to isc_result: 14: Bad address
|
|
client: UDP client handler shutting down due to fatal receive error: unexpected error</programlisting>
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is the result of a Linux kernel bug.
|
|
</para>
|
|
<para>
|
|
See:
|
|
<ulink url="http://marc.theaimsgroup.com/?l=linux-netdev&m=113081708031466&w=2"><http://marc.theaimsgroup.com/?l=linux-netdev&m=113081708031466&w=2></ulink>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why does named lock up when it attempts to connect over IPSEC tunnels?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is due to a kernel bug where the fact that a socket is marked
|
|
non-blocking is ignored. It is reported that setting
|
|
xfrm_larval_drop to 1 helps but this may have negative side effects.
|
|
See:
|
|
<ulink url="https://bugzilla.redhat.com/show_bug.cgi?id=427629"><https://bugzilla.redhat.com/show_bug.cgi?id=427629></ulink>
|
|
and
|
|
<ulink url="http://lkml.org/lkml/2007/12/4/260"><http://lkml.org/lkml/2007/12/4/260></ulink>.
|
|
</para>
|
|
<para>
|
|
xfrm_larval_drop can be set to 1 by the following procedure:
|
|
<programlisting>
|
|
echo "1" > proc/sys/net/core/xfrm_larval_drop</programlisting>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why do I see 5 (or more) copies of named on Linux?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Linux threads each show up as a process under ps. The
|
|
approximate number of threads running is n+4, where n is
|
|
the number of CPUs. Note that the amount of memory used
|
|
is not cumulative; if each process is using 10M of memory,
|
|
only a total of 10M is used.
|
|
</para>
|
|
<para>
|
|
Newer versions of Linux's ps command hide the individual threads
|
|
and require -L to display them.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Why does BIND 9 log <quote>permission denied</quote> errors accessing
|
|
its configuration files or zones on my Linux system even
|
|
though it is running as root?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
On Linux, BIND 9 drops most of its root privileges on
|
|
startup. This including the privilege to open files owned
|
|
by other users. Therefore, if the server is running as
|
|
root, the configuration files and zone files should also
|
|
be owned by root.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get the error message <quote>named: capset failed: Operation
|
|
not permitted</quote> when starting named.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
The capability module, part of "Linux Security Modules/LSM",
|
|
has not been loaded into the kernel. See insmod(8), modprobe(8).
|
|
</para>
|
|
<para>
|
|
The relevant modules can be loaded by running:
|
|
<programlisting>
|
|
modprobe commoncap
|
|
modprobe capability</programlisting>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I'm running BIND on Red Hat Enterprise Linux or Fedora Core -
|
|
</para>
|
|
<para>
|
|
Why can't named update slave zone database files?
|
|
</para>
|
|
<para>
|
|
Why can't named create DDNS journal files or update
|
|
the master zones from journals?
|
|
</para>
|
|
<para>
|
|
Why can't named create custom log files?
|
|
</para>
|
|
</question>
|
|
|
|
<answer>
|
|
<para>
|
|
Red Hat Security Enhanced Linux (SELinux) policy security
|
|
protections :
|
|
</para>
|
|
|
|
<para>
|
|
Red Hat have adopted the National Security Agency's
|
|
SELinux security policy (see <ulink
|
|
url="http://www.nsa.gov/selinux"><http://www.nsa.gov/selinux></ulink>)
|
|
and recommendations for BIND security , which are more
|
|
secure than running named in a chroot and make use of
|
|
the bind-chroot environment unnecessary .
|
|
</para>
|
|
|
|
<para>
|
|
By default, named is not allowed by the SELinux policy
|
|
to write, create or delete any files EXCEPT in these
|
|
directories:
|
|
<informalexample>
|
|
<programlisting>
|
|
$ROOTDIR/var/named/slaves
|
|
$ROOTDIR/var/named/data
|
|
$ROOTDIR/var/tmp
|
|
</programlisting>
|
|
</informalexample>
|
|
where $ROOTDIR may be set in /etc/sysconfig/named if
|
|
bind-chroot is installed.
|
|
</para>
|
|
|
|
<para>
|
|
The SELinux policy particularly does NOT allow named to modify
|
|
the $ROOTDIR/var/named directory, the default location for master
|
|
zone database files.
|
|
</para>
|
|
|
|
<para>
|
|
SELinux policy overrules file access permissions - so
|
|
even if all the files under /var/named have ownership
|
|
named:named and mode rw-rw-r--, named will still not be
|
|
able to write or create files except in the directories
|
|
above, with SELinux in Enforcing mode.
|
|
</para>
|
|
|
|
<para>
|
|
So, to allow named to update slave or DDNS zone files,
|
|
it is best to locate them in $ROOTDIR/var/named/slaves,
|
|
with named.conf zone statements such as:
|
|
<informalexample>
|
|
<programlisting>
|
|
zone "slave.zone." IN {
|
|
type slave;
|
|
file "slaves/slave.zone.db";
|
|
...
|
|
};
|
|
zone "ddns.zone." IN {
|
|
type master;
|
|
allow-updates {...};
|
|
file "slaves/ddns.zone.db";
|
|
};
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
To allow named to create its cache dump and statistics
|
|
files, for example, you could use named.conf options
|
|
statements such as:
|
|
<informalexample>
|
|
<programlisting>
|
|
options {
|
|
...
|
|
dump-file "/var/named/data/cache_dump.db";
|
|
statistics-file "/var/named/data/named_stats.txt";
|
|
...
|
|
};
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
You can also tell SELinux to allow named to update any
|
|
zone database files, by setting the SELinux tunable boolean
|
|
parameter 'named_write_master_zones=1', using the
|
|
system-config-securitylevel GUI, using the 'setsebool'
|
|
command, or in /etc/selinux/targeted/booleans.
|
|
</para>
|
|
|
|
<para>
|
|
You can disable SELinux protection for named entirely by
|
|
setting the 'named_disable_trans=1' SELinux tunable boolean
|
|
parameter.
|
|
</para>
|
|
|
|
<para>
|
|
The SELinux named policy defines these SELinux contexts for named:
|
|
<informalexample>
|
|
<programlisting>
|
|
named_zone_t : for zone database files - $ROOTDIR/var/named/*
|
|
named_conf_t : for named configuration files - $ROOTDIR/etc/{named,rndc}.*
|
|
named_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,data}}
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
If you want to retain use of the SELinux policy for named,
|
|
and put named files in different locations, you can do
|
|
so by changing the context of the custom file locations
|
|
.
|
|
</para>
|
|
|
|
<para>
|
|
To create a custom configuration file location, e.g.
|
|
'/root/named.conf', to use with the 'named -c' option,
|
|
do:
|
|
<informalexample>
|
|
<programlisting>
|
|
# chcon system_u:object_r:named_conf_t /root/named.conf
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
To create a custom modifiable named data location, e.g.
|
|
'/var/log/named' for a log file, do:
|
|
<informalexample>
|
|
<programlisting>
|
|
# chcon system_u:object_r:named_cache_t /var/log/named
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
To create a custom zone file location, e.g. /root/zones/, do:
|
|
<informalexample>
|
|
<programlisting>
|
|
# chcon system_u:object_r:named_zone_t /root/zones/{.,*}
|
|
</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
|
|
<para>
|
|
See these man-pages for more information : selinux(8),
|
|
named_selinux(8), chcon(1), setsebool(8)
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Listening on individual IPv6 interfaces does not work.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is usually due to "/proc/net/if_inet6" not being available
|
|
in the chroot file system. Mount another instance of "proc"
|
|
in the chroot file system.
|
|
</para>
|
|
<para>
|
|
This can be be made permanent by adding a second instance to
|
|
/etc/fstab.
|
|
<informalexample>
|
|
<programlisting>
|
|
proc /proc proc defaults 0 0
|
|
proc /var/named/proc proc defaults 0 0</programlisting>
|
|
</informalexample>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- Linux -->
|
|
|
|
<qandadiv><title>Windows</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
Zone transfers from my BIND 9 master to my Windows 2000
|
|
slave fail. Why?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This may be caused by a bug in the Windows 2000 DNS server
|
|
where DNS messages larger than 16K are not handled properly.
|
|
This can be worked around by setting the option "transfer-format
|
|
one-answer;". Also check whether your zone contains domain
|
|
names with embedded spaces or other special characters,
|
|
like "John\032Doe\213s\032Computer", since such names have
|
|
been known to cause Windows 2000 slaves to incorrectly
|
|
reject the zone.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I get <quote>Error 1067</quote> when starting named under Windows.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
This is the service manager saying that named exited. You
|
|
need to examine the Application log in the EventViewer to
|
|
find out why.
|
|
</para>
|
|
<para>
|
|
Common causes are that you failed to create "named.conf"
|
|
(usually "C:\windows\dns\etc\named.conf") or failed to
|
|
specify the directory in named.conf.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
options {
|
|
Directory "C:\windows\dns\etc";
|
|
};</programlisting>
|
|
</informalexample>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- Windows -->
|
|
|
|
<qandadiv><title>FreeBSD</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
I have FreeBSD 4.x and "rndc-confgen -a" just sits there.
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
/dev/random is not configured. Use rndcontrol(8) to tell
|
|
the kernel to use certain interrupts as a source of random
|
|
events. You can make this permanent by setting rand_irqs
|
|
in /etc/rc.conf.
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
/etc/rc.conf
|
|
rand_irqs="3 14 15"</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
See also
|
|
<ulink url="http://people.freebsd.org/~dougb/randomness.html">
|
|
<http://people.freebsd.org/~dougb/randomness.html></ulink>.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv> <!-- FreeBSD -->
|
|
|
|
<qandadiv><title>Solaris</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How do I integrate BIND 9 and Solaris SMF
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
Sun has a blog entry describing how to do this.
|
|
</para>
|
|
<para>
|
|
<ulink
|
|
url="http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris">
|
|
<http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris>
|
|
</ulink>
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv>
|
|
|
|
<qandadiv><title>Apple Mac OS X</title>
|
|
|
|
<qandaentry>
|
|
<question>
|
|
<para>
|
|
How do I run BIND 9 on Apple Mac OS X?
|
|
</para>
|
|
</question>
|
|
<answer>
|
|
<para>
|
|
If you run Tiger(Mac OS 10.4) or later then this is all you need to do:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
% sudo rndc-confgen > /etc/rndc.conf</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
Copy the key statement from /etc/rndc.conf into /etc/rndc.key, e.g.:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
key "rndc-key" {
|
|
algorithm hmac-md5;
|
|
secret "uvceheVuqf17ZwIcTydddw==";
|
|
};</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
Then start the relevant service:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
% sudo service org.isc.named start</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
This is persistent upon a reboot, so you will have to do it only once.
|
|
</para>
|
|
</answer>
|
|
|
|
<answer>
|
|
<para>
|
|
Alternatively you can just generate /etc/rndc.key by running:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
% sudo rndc-confgen -a</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
Then start the relevant service:
|
|
</para>
|
|
<informalexample>
|
|
<programlisting>
|
|
% sudo service org.isc.named start</programlisting>
|
|
</informalexample>
|
|
<para>
|
|
Named will look for /etc/rndc.key when it starts if it
|
|
doesn't have a controls section or the existing controls are
|
|
missing keys sub-clauses. This is persistent upon a
|
|
reboot, so you will have to do it only once.
|
|
</para>
|
|
</answer>
|
|
</qandaentry>
|
|
|
|
</qandadiv>
|
|
|
|
</qandadiv> <!-- Operating-System Specific Questions -->
|
|
|
|
</qandaset>
|
|
</article>
|