Add a section covering BIND9, more work is needed here.
This commit is contained in:
parent
24da267c32
commit
9ebdeea29e
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=22566
1 changed files with 182 additions and 0 deletions
|
@ -4010,6 +4010,188 @@ zone "10.168.192.in-addr.arpa" in {
|
|||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="network-bind9">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Tom</firstname>
|
||||
<surname>Rhodes</surname>
|
||||
<contrib>Written by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect1info>
|
||||
<title><acronym>BIND</acronym>9 and &os;</title>
|
||||
|
||||
<!-- This section is here to get users up with BIND9 configurations! It
|
||||
does not cover the terminology, theoretical discussion (why run a name
|
||||
server) or the further reading which is still in the previous section.
|
||||
I did things this way to avoid repetition of content and obviously we
|
||||
cannot just remove the previous section since other supported releases
|
||||
use it. When the previous section is removed then those comments
|
||||
should be moved here. // Tom Rhodes -->
|
||||
|
||||
<indexterm><primary>bind9</primary>
|
||||
<secondary>setting up</secondary></indexterm>
|
||||
|
||||
<para>The release of &os; 5.3 brought the
|
||||
<acronym>BIND</acronym>9 <acronym>DNS</acronym> server software
|
||||
into the distribution. New security features, a new file system
|
||||
layout and automated &man.chroot.8; configuration came with the
|
||||
import. This section has been written in two parts, the first
|
||||
will discuss new features and their configuration; the latter
|
||||
will cover upgrades to aid in move to &os; 5.3. From this
|
||||
moment on, the server will be referred to simply as
|
||||
&man.named.8; in place of <acronym>BIND</acronym>. This section
|
||||
skips over the terminology described in the previous section as
|
||||
well as some of the theoretical discussions; thus, it is
|
||||
recommended that the previous section be consulted before reading
|
||||
any further here.</para>
|
||||
|
||||
<para>Configuration files for <command>named</command> currently
|
||||
reside in
|
||||
<filename role="directory">/var/named/etc/namedb/</filename> and
|
||||
will need modification before use. This is where most of the
|
||||
configuration will be performed.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Configuration of a Master Zone</title>
|
||||
|
||||
<para>To configure a master zone visit
|
||||
<filename role="directory">/var/named/etc/namedb/</filename>
|
||||
and run the following command:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>sh make-localhost</userinput></screen>
|
||||
|
||||
<para>If all went well a new file should exist in the
|
||||
<filename role="directory">master</filename> directory. The
|
||||
filenames should be <filename>localhost.rev</filename> for
|
||||
the local domain name and <filename>localhost-v6.rev</filename>
|
||||
for <acronym>IPv6</acronym> configurations. As the default
|
||||
configuration file, configuration for its use will already
|
||||
be present in the <filename>named.conf</filename> file.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuration of a Slave Zone</title>
|
||||
|
||||
<para>Configuration for extra domains or sub domains may be
|
||||
done properly by setting them as a slave zone. In most cases,
|
||||
the <filename>master/localhost.rev</filename> could just be
|
||||
copied over into the <filename role="directory">slave</filename>
|
||||
directory and modified. Once completed, the files need
|
||||
to be properly added in <filename>named.conf</filename> such
|
||||
as in the following configuration for
|
||||
<hostid role="fqdn">example.com</hostid>:</para>
|
||||
|
||||
<programlisting>zone "example.com" {
|
||||
type slave;
|
||||
file "slave/example.com";
|
||||
masters {
|
||||
10.0.0.1;
|
||||
};
|
||||
};
|
||||
|
||||
zone "0.168.192.in-addr.arpa" {
|
||||
type slave;
|
||||
file "slave/0.168.192.in-addr.arpa";
|
||||
masters {
|
||||
10.0.0.1;
|
||||
};
|
||||
};</programlisting>
|
||||
|
||||
<para>Note well that in this example, the master
|
||||
<acronym>IP</acronym> address is the primary domain server
|
||||
from which the zones are transferred; it does not necessary serve
|
||||
as <acronym>DNS</acronym> server itself.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>System Initialization Configuration</title>
|
||||
|
||||
<para>In order for the <command>named</command> daemon to start
|
||||
when the system is booted, the following option must be present
|
||||
in the <filename>rc.conf</filename> file:</para>
|
||||
|
||||
<programlisting>named_enable="YES"</programlisting>
|
||||
|
||||
<para>While other options exist, this is the bare minimal
|
||||
requirement. Consult the &man.rc.conf.5; manual page for
|
||||
a list of the other options. If nothing is entered in the
|
||||
<filename>rc.conf</filename> file then <command>named</command>
|
||||
may be started on the command line by invoking:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>/etc/rc.d/named start</userinput></screen>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title><acronym>BIND</acronym>9 Security</title>
|
||||
|
||||
<para>While &os automatically drops <command>named</command>
|
||||
into a &man.chroot.8; environment; there are several other
|
||||
security mechanisms in place which could help to lure off
|
||||
possible <acronym>DNS</acronym> service attacks.
|
||||
|
||||
<sect3>
|
||||
<title>Query Access Control Lists</title>
|
||||
|
||||
<para>A query access control list can be used to restrict
|
||||
queries against the zones. The configuration works by
|
||||
defining the network inside of the <literal>acl</literal>
|
||||
token and then listing <acronym>IP</acronym> addresses in
|
||||
the zone configuration. To permit domains to query the
|
||||
example host, just define it like this:</para>
|
||||
|
||||
<programlisting>acl "example.com" {
|
||||
192.168.0.0/24;
|
||||
};
|
||||
|
||||
zone "example.com" {
|
||||
type slave;
|
||||
file "slave/example.com";
|
||||
masters {
|
||||
10.0.0.1;
|
||||
};
|
||||
allow-query { example.com; };
|
||||
};
|
||||
|
||||
zone "0.168.192.in-addr.arpa" {
|
||||
type slave;
|
||||
file "slave/0.168.192.in-addr.arpa";
|
||||
masters {
|
||||
10.0.0.1;
|
||||
};
|
||||
allow-query { example.com; };
|
||||
};</programlisting>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Restrict Version</title>
|
||||
|
||||
<para>Permitting version lookups on the <acronym>DNS</acronym>
|
||||
server could be opening the doors for an attacker. A
|
||||
malicious user may use this information to hunt up known
|
||||
exploits or bugs to utilize against the host. A false version
|
||||
string can be placed the <literal>options</literal> section of
|
||||
<filename>named.conf</filename>:</para>
|
||||
|
||||
<programlisting>options {
|
||||
directory "/etc/namedb";
|
||||
pid-file "/var/run/named/pid";
|
||||
dump-file "/var/dump/named_dump.db";
|
||||
statistics-file "/var/stats/named.stats";
|
||||
version "None of your business";</programlisting>
|
||||
</sect3>
|
||||
<!-- Here is where I stopped for now
|
||||
<sect3>
|
||||
<title>Authentication</title>
|
||||
|
||||
<para> ... </para>
|
||||
|
||||
-->
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
||||
<sect1 id="network-apache">
|
||||
<sect1info>
|
||||
<authorgroup>
|
||||
|
|
Loading…
Reference in a new issue