DNS part of the manual
Daniel Gerzo
danger at rulez.sk
Mon May 15 23:19:07 UTC 2006
Hello Tom,
As I've promised, I've worked out a bit that DNS chapter and it's
mostly done so it needs some review. Please see the attached diff,
and post comments. A lot of whitespaces were cleaned-up as well as
some style nits were corrected. There are still some lines more than
72 chars longer, but I would say those are just fine.
Built version is available at:
http://www.sk.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns-new.html
--
Sincerely,
Daniel Gerzo
-------------- next part --------------
--- chapter.sgml.orig Sun May 14 20:37:53 2006
+++ chapter.sgml Mon May 15 23:09:58 2006
@@ -2926,63 +2926,67 @@
<sect1 id="network-dns">
<sect1info>
<authorgroup>
- <author>
- <firstname>Chern</firstname>
- <surname>Lee</surname>
- <contrib>Contributed by </contrib>
- </author>
+ <author>
+ <firstname>Chern</firstname>
+ <surname>Lee</surname>
+ <contrib>Contributed by </contrib>
+ </author>
+
+ <author>
+ <firstname>Tom</firstname>
+ <surname>Rhodes</surname>
+ </author>
+
+ <author>
+ <firstname>Daniel</firstname>
+ <surname>Gerzo</surname>
+ </author>
</authorgroup>
</sect1info>
- <title>Domain Name System (DNS)</title>
+ <title>Domain Name System (<acronym>DNS</acronym>)</title>
<sect2>
<title>Overview</title>
<indexterm><primary>BIND</primary></indexterm>
- <para>FreeBSD utilizes, by default, a version of BIND (Berkeley
- Internet Name Domain), which is the most common implementation
- of the DNS protocol. DNS is the protocol through which names
- are mapped to IP addresses, and vice versa. For example, a
- query for <hostid role="fqdn">www.FreeBSD.org</hostid> will
- receive a reply with the IP address of The FreeBSD Project's
- web server, whereas, a query for <hostid
- role="fqdn">ftp.FreeBSD.org</hostid> will return the IP
- address of the corresponding FTP machine. Likewise, the
- opposite can happen. A query for an IP address can resolve
- its hostname. It is not necessary to run a name server to
- perform DNS lookups on a system.
- </para>
+ <para>&os; utilizes, by default, a version of BIND (Berkeley
+ Internet Name Domain), which is the most common implementation
+ of the <acronym>DNS</acronym> protocol. <acronym>DNS</acronym>
+ is the protocol through which names are mapped to
+ <acronym>IP</acronym> addresses, and vice versa. For example, a
+ query for <hostid role="fqdn">www.FreeBSD.org</hostid> will
+ receive a reply with the <acronym>IP</acronym> address of The
+ &os; Project's web server, whereas, a query for <hostid
+ role="fqdn">ftp.FreeBSD.org</hostid> will return the
+ <acronym>IP</acronym> address of the corresponding
+ <acronym>FTP</acronym> machine. Likewise, the opposite can
+ happen. A query for an <acronym>IP</acronym> address can
+ resolve its hostname. It is not necessary to run a name server
+ to perform <acronym>DNS</acronym> lookups on a system.</para>
+
+ <para>&os; currently comes with <acronym>BIND</acronym>9
+ <acronym>DNS</acronym> server software by default. This version
+ provides enhanced security features, a new file system layout
+ and automated &man.chroot.8; configuration.</para>
<indexterm><primary>DNS</primary></indexterm>
- <para>DNS is coordinated across the Internet through a somewhat
- complex system of authoritative root name servers, and other
- smaller-scale name servers who host and cache individual domain
- information.
- </para>
-
- <para>
- This document refers to BIND 8.x, as it is the stable version
- used in &os;. Versions of &os; 5.3 and beyond include
- <acronym>BIND</acronym>9 and the configuration instructions
- may be found later in this chapter. Users of &os; 5.2
- and other previous versions may install <acronym>BIND</acronym>9
- from the <filename role="package">net/bind9</filename> port.</para>
-
- <para>
- RFC1034 and RFC1035 dictate the DNS protocol.
- </para>
-
- <para>
- Currently, BIND is maintained by the
- Internet Software Consortium <ulink url="http://www.isc.org/"></ulink>.
- </para>
+ <para><acronym>DNS</acronym> is coordinated across the Internet
+ through a somewhat complex system of authoritative root name
+ servers, and other smaller-scale name servers who host and cache
+ individual domain information. This protocol is dictated by
+ <acronym>RFC</acronym> 1034 and <acronym>RFC</acronym>
+ 1035.</para>
+
+ <para>Currently, BIND is maintained by the
+ Internet Software Consortium
+ <ulink url="http://www.isc.org/"></ulink>.</para>
</sect2>
<sect2>
<title>Terminology</title>
- <para>To understand this document, some terms related to DNS must be
- understood.</para>
+ <para>To understand this document, some terms related to
+ <acronym>DNS</acronym> must be understood.</para>
<indexterm><primary>resolver</primary></indexterm>
<indexterm><primary>reverse DNS</primary></indexterm>
@@ -3001,32 +3005,33 @@
<tbody>
<row>
- <entry>Forward DNS</entry>
- <entry>Mapping of hostnames to IP addresses</entry>
+ <entry>Forward <acronym>DNS</acronym></entry>
+ <entry>Mapping of hostnames to IP addresses.</entry>
</row>
<row>
<entry>Origin</entry>
<entry>Refers to the domain covered in a particular zone
- file</entry>
+ file.</entry>
</row>
<row>
<entry><application>named</application>, BIND, name server</entry>
<entry>Common names for the BIND name server package within
- FreeBSD</entry>
+ &os;.</entry>
</row>
<row>
<entry>Resolver</entry>
<entry>A system process through which a
- machine queries a name server for zone information</entry>
+ machine queries a name server for zone information.</entry>
</row>
<row>
- <entry>Reverse DNS</entry>
- <entry>The opposite of forward DNS; mapping of IP addresses to
- hostnames</entry>
+ <entry>Reverse <acronym>DNS</acronym></entry>
+ <entry>The opposite of forward <acronym>DNS</acronym>;
+ mapping of <acronym>IP</acronym> addresses to
+ hostnames.</entry>
</row>
<row>
@@ -3034,13 +3039,15 @@
<entry>The beginning of the Internet zone hierarchy.
All zones fall under the root zone, similar to how
- all files in a file system fall under the root directory.</entry>
+ all files in a file system fall under the root
+ directory.</entry>
</row>
<row>
<entry>Zone</entry>
- <entry>An individual domain, subdomain, or portion of the DNS administered by
- the same authority</entry>
+ <entry>An individual domain, subdomain, or portion of the
+ <acronym>DNS</acronym> administered by the same
+ authority.</entry>
</row>
</tbody>
</tgroup>
@@ -3051,43 +3058,44 @@
<secondary>examples</secondary>
</indexterm>
- <para>Examples of zones:
- </para>
+ <para>Examples of zones:</para>
+
<itemizedlist>
- <listitem>
- <para><hostid>.</hostid> is the root zone</para>
- </listitem>
- <listitem>
- <para><hostid>org.</hostid> is a zone under the root zone</para>
- </listitem>
- <listitem>
- <para><hostid role="domainname">example.org.</hostid> is a
- zone under the <hostid>org.</hostid> zone</para>
- </listitem>
- <listitem>
- <para><hostid role="domainname">foo.example.org.</hostid> is
- a subdomain, a zone under the <hostid
- role="domainname">example.org.</hostid> zone</para>
- </listitem>
- <listitem>
- <para>
- <hostid>1.2.3.in-addr.arpa</hostid> is a zone referencing
- all IP addresses which fall under the <hostid
- role="ipaddr">3.2.1.*</hostid> IP space.
- </para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para><hostid>.</hostid> is the root zone.</para>
+ </listitem>
+
+ <listitem>
+ <para><hostid>org.</hostid> is a zone under the root zone.</para>
+ </listitem>
- <para>As one can see, the more specific part of a hostname
- appears to its left. For example, <hostid
- role="domainname">example.org.</hostid> is more specific than
- <hostid>org.</hostid>, as <hostid>org.</hostid> is more
- specific than the root zone. The layout of each part of a
- hostname is much like a file system: the
- <filename>/dev</filename> directory falls within the root, and
- so on.</para>
+ <listitem>
+ <para><hostid role="domainname">example.org.</hostid> is a
+ zone under the <hostid>org.</hostid> zone.</para>
+ </listitem>
+
+ <listitem>
+ <para><hostid role="domainname">foo.example.org.</hostid> is
+ a subdomain, a zone under the <hostid
+ role="domainname">example.org.</hostid> zone.</para>
+ </listitem>
+ <listitem>
+ <para><hostid>1.2.3.in-addr.arpa</hostid> is a zone
+ referencing all <acronym>IP</acronym> addresses which fall
+ under the <hostid role="ipaddr">3.2.1.*</hostid>
+ <acronym>IP</acronym> space.</para>
+ </listitem>
+ </itemizedlist>
+ <para>As one can see, the more specific part of a hostname appears
+ to its left. For example, <hostid
+ role="domainname">example.org.</hostid> is more specific than
+ <hostid>org.</hostid>, as <hostid>org.</hostid> is more specific
+ than the root zone. The layout of each part of a hostname is
+ much like a file system: the
+ <filename role="directory">/dev</filename> directory falls
+ within the root, and so on.</para>
</sect2>
<sect2>
@@ -3100,21 +3108,25 @@
<itemizedlist>
<listitem>
- <para>one wants to serve DNS information to the
- world, replying authoritatively to queries.</para>
+ <para>one wants to serve <acronym>DNS</acronym> information to
+ the world, replying authoritatively to queries.</para>
</listitem>
+
<listitem>
- <para>a domain, such as <hostid role="domainname">example.org</hostid>, is
- registered and IP addresses need to be assigned to hostnames
- under it.</para>
+ <para>a domain, such as <hostid role="domainname">example.org</hostid>,
+ is registered and <acronym>IP</acronym> addresses need to be
+ assigned to hostnames under it.</para>
</listitem>
+
<listitem>
- <para>an IP address block requires reverse DNS entries (IP to
+ <para>an <acronym>IP</acronym> address block requires reverse
+ <acronym>DNS</acronym> entries (<acronym>IP</acronym> to
hostname).</para>
</listitem>
+
<listitem>
- <para>a backup name server, called a slave, must reply to queries
- when the primary is down or inaccessible.</para>
+ <para>a backup name server, called a slave, must reply to
+ queries when the primary is down or inaccessible.</para>
</listitem>
</itemizedlist>
@@ -3122,30 +3134,31 @@
<itemizedlist>
<listitem>
- <para>a local DNS server may cache and respond more quickly
- than querying an outside name server.</para>
+ <para>a local <acronym>DNS</acronym> server may cache and
+ respond more quickly than querying an outside name server.</para>
</listitem>
+
<listitem>
- <para>a reduction in overall network traffic is desired (DNS
- traffic has been measured to account for 5% or more of total
- Internet traffic).</para>
+ <para>a reduction in overall network traffic is desired
+ (<acronym>DNS</acronym> traffic has been measured to account
+ for 5% or more of total Internet traffic).</para>
</listitem>
</itemizedlist>
<para>When one queries for <hostid
role="fqdn">www.FreeBSD.org</hostid>, the resolver usually
- queries the uplink ISP's name server, and retrieves the reply.
- With a local, caching DNS server, the query only has to be
- made once to the outside world by the caching DNS server.
- Every additional query will not have to look to the outside of
- the local network, since the information is cached
+ queries the uplink <acronym>ISP</acronym>'s name server, and
+ retrieves the reply. With a local, caching
+ <acronym>DNS</acronym> server, the query only has to be made
+ once to the outside world by the caching <acronym>DNS</acronym>
+ server. Every additional query will not have to look to the
+ outside of the local network, since the information is cached
locally.</para>
-
</sect2>
<sect2>
<title>How It Works</title>
- <para>In FreeBSD, the BIND daemon is called
+ <para>In &os;, the BIND daemon is called
<application>named</application> for obvious reasons.</para>
<informaltable frame="none" pgwide="1">
@@ -3159,961 +3172,547 @@
<tbody>
<row>
- <entry><application>named</application></entry>
- <entry>the BIND daemon</entry>
+ <entry>&man.named.8;</entry>
+ <entry>The BIND daemon.</entry>
</row>
<row>
- <entry><command>ndc</command></entry>
- <entry>name daemon control program</entry>
+ <entry>&man.rndc.8;</entry>
+ <entry>Name server control utility.</entry>
</row>
<row>
- <entry><filename>/etc/namedb</filename></entry>
- <entry>directory where BIND zone information resides</entry>
+ <entry><filename role="directory">/etc/namedb</filename></entry>
+ <entry>Directory where BIND zone information resides.</entry>
</row>
<row>
<entry><filename>/etc/namedb/named.conf</filename></entry>
- <entry>daemon configuration file</entry>
+ <entry>Configuration file off the daemon.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
- <para>
- Zone files are usually contained within the
- <filename>/etc/namedb</filename>
- directory, and contain the DNS zone information
- served by the name server.
- </para>
+ <para>Zone files are usually contained in
+ <filename role="directory">master/</filename> and
+ <filename role="directory">slave/</filename> subdirectories
+ within the <filename role="directory">/etc/namedb</filename>
+ directory, depending on the type of the zone, which contain the
+ DNS zone information served by the name server.</para>
</sect2>
<sect2>
<title>Starting BIND</title>
<indexterm>
- <primary>BIND</primary>
+ <primary>BIND</primary>
<secondary>starting</secondary>
</indexterm>
- <para>
- Since BIND is installed by default, configuring it all is
- relatively simple.
- </para>
- <para>
- To ensure the <application>named</application> daemon is
- started at boot, put the following line in
- <filename>/etc/rc.conf</filename>:
- </para>
+
+ <para>Since BIND is installed by default, configuring it all is
+ relatively simple.</para>
+
+ <para>To ensure the <application>named</application> daemon is
+ started at boot, put the following line in
+ <filename>/etc/rc.conf</filename>:</para>
+
<programlisting>named_enable="YES"</programlisting>
- <para>To start the daemon manually (after configuring it):</para>
- <screen>&prompt.root; <userinput>ndc start</userinput></screen>
+
+ <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
+ <application>named</application> may be started (after
+ configuring it) on the command line by invocation of the
+ following command:</para>
+
+ <screen>&prompt.root; <userinput>/etc/rc.d/named start</userinput></screen>
</sect2>
<sect2>
<title>Configuration Files</title>
<indexterm>
- <primary>BIND</primary>
+ <primary>BIND</primary>
<secondary>configuration files</secondary>
</indexterm>
+
+ <para>Configuration files for <application>named</application>
+ currently reside in
+ <filename role="directory">/etc/namedb/</filename> directory and
+ will need modification before use. This is where most of the
+ configuration will be performed.</para>
+
<sect3>
- <title>Using <command>make-localhost</command></title>
- <para>Be sure to:
- </para>
- <screen>&prompt.root; <userinput>cd /etc/namedb</userinput>
-&prompt.root; <userinput>sh make-localhost</userinput></screen>
- <para>to properly create the local reverse DNS zone file in
- <filename>/etc/namedb/master/localhost.rev</filename>.
- </para>
+ <title>Using <command>make-localhost</command></title>
+
+ <para>To configure a master zone for local hostname visit the
+ <filename role="directory">/etc/namedb/</filename> directory
+ 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 class="directory">master/</filename> subdirectory.
+ 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>
</sect3>
<sect3>
- <title><filename>/etc/namedb/named.conf</filename></title>
+ <title><filename>/etc/namedb/named.conf</filename></title>
- <programlisting>// $FreeBSD$
+ <programlisting>// $FreeBSD: src/etc/namedb/named.conf,v 1.21.2.1 2005/09/10 08:27:27 dougb Exp $
//
-// Refer to the named(8) manual page for details. If you are ever going
-// to setup a primary server, make sure you've understood the hairy
-// details of how DNS is working. Even with simple mistakes, you can
-// break connectivity for affected parties, or cause huge amount of
-// useless Internet traffic.
+// Refer to the named.conf(5) and named(8) man pages, and the documentation
+// in /usr/share/doc/bind9 for more details.
+//
+// If you are going to set up an authoritative server, make sure you
+// understand the hairy details of how DNS works. Even with
+// simple mistakes, you can break connectivity for affected parties,
+// or cause huge amounts of useless Internet traffic.
options {
- directory "/etc/namedb";
+ directory "/etc/namedb";
+ pid-file "/var/run/named/pid";
+ dump-file "/var/dump/named_dump.db";
+ statistics-file "/var/stats/named.stats";
+
+// If named is being used only as a local resolver, this is a safe default.
+// For named to be accessible to the network, comment this option, specify
+// the proper IP address, or delete this option.
+ listen-on { 127.0.0.1; };
+
+// If you have IPv6 enabled on this system, uncomment this option for
+// use as a local resolver. To give access to the network, specify
+// an IPv6 address, or the keyword "any".
+// listen-on-v6 { ::1; };
// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
-// forward only;
+// forward only;
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
-// benefit from its cache, thus reduce overall DNS traffic in the
-Internet.
+// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
- forwarders {
- 127.0.0.1;
- };
+ forwarders {
+ 127.0.0.1;
+ };
*/</programlisting>
- <para>
- Just as the comment says, to benefit from an uplink's cache,
- <literal>forwarders</literal> can be enabled here. Under normal
- circumstances, a name server will recursively query the Internet
- looking at certain name servers until it finds the answer it is
- looking for. Having this enabled will have it query the uplink's
- name server (or name server provided) first, taking advantage of
- its cache. If the uplink name server in question is a heavily
- trafficked, fast name server, enabling this may be worthwhile.
- </para>
-
- <warning><para><hostid role="ipaddr">127.0.0.1</hostid>
- will <emphasis>not</emphasis> work here.
- Change this IP address to a name server at your uplink.</para>
- </warning>
-
- <programlisting> /*
- * If there is a firewall between you and name servers you want
- * to talk to, you might need to uncomment the query-source
- * directive below. Previous versions of BIND always asked
- * questions using port 53, but BIND 8.1 uses an unprivileged
- * port by default.
- */
- // query-source address * port 53;
-
- /*
- * If running in a sandbox, you may have to specify a different
- * location for the dumpfile.
- */
- // dump-file "s/named_dump.db";
-};
+ <para>Just as the comment says, to benefit from an uplink's
+ cache, <literal>forwarders</literal> can be enabled here.
+ Under normal circumstances, a name server will recursively
+ query the Internet looking at certain name servers until it
+ finds the answer it is looking for. Having this enabled will
+ have it query the uplink's name server (or name server
+ provided) first, taking advantage of its cache. If the uplink
+ name server in question is a heavily trafficked, fast name
+ server, enabling this may be worthwhile.</para>
-// Note: the following will be supported in a future release.
-/*
-host { any; } {
- topology {
- 127.0.0.0/8;
- };
+ <warning>
+ <para><hostid role="ipaddr">127.0.0.1</hostid> will
+ <emphasis>not</emphasis> work here. Change this
+ <acronym>IP</acronym> address to a name server at your
+ uplink.</para>
+ </warning>
+
+ <programlisting> /*
+ * If there is a firewall between you and nameservers you want
+ * to talk to, you might need to uncomment the query-source
+ * directive below. Previous versions of BIND always asked
+ * questions using port 53, but BIND versions 8 and later
+ * use a pseudo-random unprivileged UDP port by default.
+ */
+ // query-source address * port 53;
};
-*/
-// Setting up secondaries is way easier and the rough picture for this
-// is explained below.
-//
// If you enable a local name server, don't forget to enter 127.0.0.1
-// into your /etc/resolv.conf so this server will be queried first.
+// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.
zone "." {
- type hint;
- file "named.root";
+ type hint;
+ file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
- type master;
- file "localhost.rev";
+ type master;
+ file "master/localhost.rev";
+};
+
+// RFC 3152
+zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA" {
+ type master;
+ file "master/localhost-v6.rev";
};
// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
-// Example secondary config entries. It can be convenient to become
-// a secondary at least for the zone where your own domain is in. Ask
+// Example slave zone config entries. It can be convenient to become
+// a slave at least for the zone your own domain is in. Ask
// your network administrator for the IP address of the responsible
// primary.
//
// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone!
-// (This is the first bytes of the respective IP address, in reverse
+// (This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended.)
//
-// Before starting to setup a primary zone, better make sure you fully
-// understand how DNS and BIND works, however. There are sometimes
-// unobvious pitfalls. Setting up a secondary is comparably simpler.
+// Before starting to set up a primary zone, make sure you fully
+// understand how DNS and BIND works. There are sometimes
+// non-obvious pitfalls. Setting up a slave zone is simpler.
//
// NB: Don't blindly enable the examples below. :-) Use actual names
// and addresses instead.
-//
-// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf).
-// The directory containing the secondary zones must be write accessible
-// to BIND. The following sequence is suggested:
-//
-// mkdir /etc/namedb/s
-// chown bind:bind /etc/namedb/s
-// chmod 750 /etc/namedb/s</programlisting>
-
- <para>For more information on running BIND in a sandbox, see
- <link linkend="network-named-sandbox">Running named in a sandbox</link>.
- </para>
- <programlisting>/*
-zone "example.com" {
- type slave;
- file "s/example.com.bak";
- masters {
- 192.168.1.1;
- };
+/* An example master zone
+zone "example.net" {
+ type master;
+ file "master/example.net";
};
+*/
-zone "0.168.192.in-addr.arpa" {
- type slave;
- file "s/0.168.192.in-addr.arpa.bak";
- masters {
- 192.168.1.1;
- };
+/* An example dynamic zone
+key "exampleorgkey" {
+ algorithm hmac-md5;
+ secret "sf87HJqjkqh8ac87a02lla==";
+};
+zone "example.org" {
+ type master;
+ allow-update {
+ key "exampleorgkey";
+ };
+ file "dynamic/example.org";
+};
+*/
+
+/* Examples of forward and reverse slave zones
+zone "example.com" {
+ type slave;
+ file "slave/example.com";
+ masters {
+ 192.168.1.1;
+ };
+};
+zone "1.168.192.in-addr.arpa" {
+ type slave;
+ file "slave/1.168.192.in-addr.arpa";
+ masters {
+ 192.168.1.1;
+ };
};
*/</programlisting>
- <para>In <filename>named.conf</filename>, these are examples of slave
- entries for a forward and reverse zone.</para>
- <para>For each new zone served, a new zone entry must be added to
- <filename>named.conf</filename>.</para>
+ <para>In <filename>named.conf</filename>, these are examples of
+ slave entries for a forward and reverse zone.</para>
- <para>For example, the simplest zone entry for
- <hostid role="domainname">example.org</hostid> can look like:</para>
+ <para>For each new zone served, a new zone entry must be added
+ to <filename>named.conf</filename>.</para>
- <programlisting>zone "example.org" {
+ <para>For example, the simplest zone entry for
+ <hostid role="domainname">example.org</hostid> can look
+ like:</para>
+
+ <programlisting>zone "example.org" {
type master;
- file "example.org";
+ file "master/example.org";
};</programlisting>
- <para>The zone is a master, as indicated by the <option>type</option>
- statement, holding its zone information in
- <filename>/etc/namedb/example.org</filename> indicated by
- the <option>file</option> statement.</para>
+ <para>The zone is a master, as indicated by the
+ <option>type</option> statement, holding its zone information
+ in <filename>/etc/namedb/master/example.org</filename>
+ indicated by the <option>file</option> statement.</para>
- <programlisting>zone "example.org" {
+ <programlisting>zone "example.org" {
type slave;
- file "example.org";
+ file "slave/example.org";
};</programlisting>
- <para>In the slave case, the zone information is transferred from
- the master name server for the particular zone, and saved in the
- file specified. If and when the master server dies or is
- unreachable, the slave name server will have the transferred
- zone information and will be able to serve it.</para>
+ <para>In the slave case, the zone information is transferred
+ from the master name server for the particular zone, and saved
+ in the file specified. If and when the master server dies or
+ is unreachable, the slave name server will have the
+ transferred zone information and will be able to serve
+ it.</para>
</sect3>
<sect3>
- <title>Zone Files</title>
- <para>
- An example master zone file for <hostid
+ <title>Zone Files</title>
+
+ <para>An example master zone file for <hostid
role="domainname">example.org</hostid> (existing within
- <filename>/etc/namedb/example.org</filename>) is as follows:
- </para>
-
- <programlisting>$TTL 3600
+ <filename>/etc/namedb/master/example.org</filename>) is as
+ follows:</para>
-example.org. IN SOA ns1.example.org. admin.example.org. (
- 5 ; Serial
- 10800 ; Refresh
- 3600 ; Retry
- 604800 ; Expire
- 86400 ) ; Minimum TTL
+ <programlisting>$TTL 3600 ; 1 hour
+example.org. IN SOA ns1.example.org. admin.example.org. (
+ 2006051501 ; Serial
+ 10800 ; Refresh
+ 3600 ; Retry
+ 604800 ; Expire
+ 86400 ; Minimum TTL
+ )
; DNS Servers
-@ IN NS ns1.example.org.
-@ IN NS ns2.example.org.
+ IN NS ns1.example.org.
+ IN NS ns2.example.org.
+; MX Records
+ IN MX 10 mx.example.org.
+ IN MX 20 mail.example.org.
+
+ IN A 3.2.1.1
; Machine Names
-localhost IN A 127.0.0.1
-ns1 IN A 3.2.1.2
-ns2 IN A 3.2.1.3
-mail IN A 3.2.1.10
-@ IN A 3.2.1.30
+localhost IN A 127.0.0.1
+ns1 IN A 3.2.1.2
+ns2 IN A 3.2.1.3
+mx IN A 3.2.1.4
+mail IN A 3.2.1.5
; Aliases
-www IN CNAME @
-
-; MX Record
-@ IN MX 10 mail.example.org.</programlisting>
+www IN CNAME localhost.example.org.</programlisting>
- <para>
- Note that every hostname ending in a <quote>.</quote> is an
- exact hostname, whereas everything without a trailing
- <quote>.</quote> is referenced to the origin. For example,
- <literal>www</literal> is translated into
- <literal>www.<replaceable>origin</replaceable></literal>.
- In our fictitious zone file, our origin is
- <hostid>example.org.</hostid>, so <literal>www</literal>
- would translate to <hostid>www.example.org.</hostid>
- </para>
-
- <para>
- The format of a zone file follows:
- </para>
- <programlisting>recordname IN recordtype value</programlisting>
+ <para>Note that every hostname ending in a <quote>.</quote> is
+ an exact hostname, whereas everything without a trailing
+ <quote>.</quote> is referenced to the origin. For example,
+ <literal>www</literal> is translated into
+ <literal>www.<replaceable>origin</replaceable></literal>.
+ In our fictitious zone file, our origin is
+ <hostid>example.org.</hostid>, so <literal>www</literal>
+ would translate to <hostid>www.example.org.</hostid></para>
+
+ <para>The format of a zone file follows:</para>
+
+ <programlisting>recordname IN recordtype value</programlisting>
<indexterm>
<primary>DNS</primary>
<secondary>records</secondary>
</indexterm>
- <para>
- The most commonly used DNS records:
- </para>
+
+ <para>The most commonly used <acronym>DNS</acronym>
+ records:</para>
<variablelist>
<varlistentry>
<term>SOA</term>
- <listitem><para>start of zone authority</para></listitem>
+ <listitem>
+ <para>Start of zone authority.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term>NS</term>
- <listitem><para>an authoritative name server</para></listitem>
+ <listitem>
+ <para>An authoritative name server.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term>A</term>
- <listitem><para>a host address</para></listitem>
+ <listitem>
+ <para>A host <acronym>IP</acronym> address.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term>CNAME</term>
- <listitem><para>the canonical name for an alias</para></listitem>
+ <listitem>
+ <para>The canonical name for an alias.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term>MX</term>
- <listitem><para>mail exchanger</para></listitem>
+ <listitem>
+ <para>Mail exchanger.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term>PTR</term>
- <listitem><para>a domain name pointer (used in reverse DNS)
- </para></listitem>
+ <listitem>
+ <para>A domain name pointer (used in reverse
+ <acronym>DNS</acronym>).</para>
+ </listitem>
</varlistentry>
</variablelist>
- <programlisting>
-example.org. IN SOA ns1.example.org. admin.example.org. (
- 5 ; Serial
- 10800 ; Refresh after 3 hours
- 3600 ; Retry after 1 hour
- 604800 ; Expire after 1 week
- 86400 ) ; Minimum TTL of 1 day</programlisting>
-
+<programlisting>example.org. IN SOA ns1.example.org. admin.example.org. (
+ 2006051501 ; Serial
+ 10800 ; Refresh after 3 hours
+ 3600 ; Retry after 1 hour
+ 604800 ; Expire after 1 week
+ 86400 ; Minimum TTL of 1 day
+ )</programlisting>
<variablelist>
<varlistentry>
<term><hostid role="domainname">example.org.</hostid></term>
- <listitem><para>the domain name, also the origin for this
- zone file.</para></listitem>
+ <listitem>
+ <para>The domain name, also the origin for this zone
+ file.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term><hostid role="fqdn">ns1.example.org.</hostid></term>
- <listitem><para>the primary/authoritative name server for this
- zone.</para></listitem>
+ <listitem>
+ <para>The primary/authoritative name server for this
+ zone.</para>
+ </listitem>
</varlistentry>
<varlistentry>
<term><literal>admin.example.org.</literal></term>
- <listitem><para>the responsible person for this zone,
- email address with <quote>@</quote>
- replaced. (<email>admin at example.org</email> becomes
+ <listitem>
+ <para>The responsible person for this zone, email address
+ with <quote>@</quote> replaced.
+ (<email>admin at example.org</email> becomes
<literal>admin.example.org</literal>)</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><literal>5</literal></term>
+ <term><literal>2006051501</literal></term>
- <listitem><para>the serial number of the file. This
- must be incremented each time the zone file is
- modified. Nowadays, many admins prefer a
- <literal>yyyymmddrr</literal> format for the serial
- number. <literal>2001041002</literal> would mean
- last modified 04/10/2001, the latter
- <literal>02</literal> being the second time the zone
- file has been modified this day. The serial number
- is important as it alerts slave name servers for a
- zone when it is updated.</para>
- </listitem>
+ <listitem>
+ <para>the serial number of the file. This must be
+ incremented each time the zone file is modified.
+ Nowadays, many admins prefer a
+ <literal>yyyymmddrr</literal> format for the serial
+ number. <literal>2006051501</literal> would mean last
+ modified 05/15/2006, the latter <literal>01</literal>
+ being the first time the zone file has been modified
+ this day. The serial number is important as it alerts
+ slave name servers for a zone when it is updated.</para>
+ </listitem>
</varlistentry>
</variablelist>
- <programlisting>
-@ IN NS ns1.example.org.</programlisting>
+ <programlisting> IN NS ns1.example.org.</programlisting>
- <para>
- This is an NS entry. Every name server that is going to reply
- authoritatively for the zone must have one of these entries.
- The <literal>@</literal> as seen here could have been
- <hostid role="domainname">example.org.</hostid>
- The <literal>@</literal> translates to the origin.
- </para>
-
- <programlisting>
-localhost IN A 127.0.0.1
-ns1 IN A 3.2.1.2
-ns2 IN A 3.2.1.3
-mail IN A 3.2.1.10
-@ IN A 3.2.1.30</programlisting>
-
- <para>
- The A record indicates machine names. As seen above,
- <hostid role="fqdn">ns1.example.org</hostid> would resolve
- to <hostid role="ipaddr">3.2.1.2</hostid>. Again, the
- origin symbol, <literal>@</literal>, is used here, thus
- meaning <hostid role="domainname">example.org</hostid> would
- resolve to <hostid role="ipaddr">3.2.1.30</hostid>.
- </para>
-
- <programlisting>
-www IN CNAME @</programlisting>
-
- <para>
- The canonical name record is usually used for giving aliases
- to a machine. In the example, <hostid>www</hostid> is
- aliased to the machine addressed to the origin, or
- <hostid role="domainname">example.org</hostid>
- (<hostid role="ipaddr">3.2.1.30</hostid>).
- CNAMEs can be used to provide alias
- hostnames, or round robin one hostname among multiple
- machines.
- </para>
+ <para>This is an <acronym>NS</acronym> entry. Every name server
+ that is going to reply authoritatively for the zone must have
+ one of these entries.</para>
+
+ <programlisting>localhost IN A 127.0.0.1
+ns1 IN A 3.2.1.2
+ns2 IN A 3.2.1.3
+mx IN A 3.2.1.4
+mail IN A 3.2.1.10</programlisting>
+
+ <para>The A record indicates machine names. As seen above,
+ <hostid role="fqdn">ns1.example.org</hostid> would resolve
+ to <hostid role="ipaddr">3.2.1.2</hostid>.</para>
+
+ <programlisting>www IN CNAME localhost.example.org.</programlisting>
+
+ <para>The canonical name record is usually used for giving
+ aliases to a machine. In the example, <hostid>www</hostid> is
+ aliased to the machine addressed to the
+ <hostid role="domainname">localhost.example.org</hostid>
+ (<hostid role="ipaddr">3.2.1.30</hostid>). CNAMEs can be used
+ to provide alias hostnames, or round robin one hostname among
+ multiple machines.</para>
<indexterm>
<primary>MX record</primary>
</indexterm>
- <programlisting>
-@ IN MX 10 mail.example.org.</programlisting>
+ <programlisting> IN MX 10 mail.example.org.</programlisting>
- <para>
- The MX record indicates which mail
- servers are responsible for handling incoming mail for the
- zone. <hostid role="fqdn">mail.example.org</hostid> is the
- hostname of the mail server, and 10 being the priority of
- that mail server.
- </para>
-
- <para>
- One can have several mail servers, with priorities of 3, 2,
- 1. A mail server attempting to deliver to <hostid
- role="domainname">example.org</hostid> would first try the
- highest priority MX, then the second highest, etc, until the
- mail can be properly delivered.
- </para>
-
- <para>
- For in-addr.arpa zone files (reverse DNS), the same format is
- used, except with PTR entries instead of
- A or CNAME.
- </para>
-
- <programlisting>$TTL 3600
-
-1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
- 5 ; Serial
- 10800 ; Refresh
- 3600 ; Retry
- 604800 ; Expire
- 3600 ) ; Minimum
-
-@ IN NS ns1.example.org.
-@ IN NS ns2.example.org.
-
-2 IN PTR ns1.example.org.
-3 IN PTR ns2.example.org.
-10 IN PTR mail.example.org.
-30 IN PTR example.org.</programlisting>
+ <para>The MX record indicates which mail servers are responsible
+ for handling incoming mail for the zone. <hostid
+ role="fqdn">mail.example.org</hostid> is the hostname of the
+ mail server, and 10 being the priority of that mail server.</para>
+
+ <para>One can have several mail servers, with priorities of 10,
+ 20, and so on. A mail server attempting to deliver to <hostid
+ role="domainname">example.org</hostid> would first try the
+ highest priority MX, then the second highest, etc, until the
+ mail can be properly delivered.</para>
+
+ <para>For in-addr.arpa zone files (reverse
+ <acronym>DNS</acronym>), the same format is used, except with
+ PTR entries instead of A or CNAME.</para>
+
+ <programlisting>$TTL 3600
+
+1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
+ 5 ; Serial
+ 10800 ; Refresh
+ 3600 ; Retry
+ 604800 ; Expire
+ 3600 ; Minimum
+ )
+
+ IN NS ns1.example.org.
+ IN NS ns2.example.org.
+
+2 IN PTR ns1.example.org.
+3 IN PTR ns2.example.org.
+10 IN PTR mail.example.org.
+30 IN PTR example.org.</programlisting>
- <para>This file gives the proper IP address to hostname
- mappings of our above fictitious domain.</para>
+ <para>This file gives the proper <acronym>IP</acronym> address
+ to hostname mappings of our above fictitious domain.</para>
</sect3>
</sect2>
<sect2>
<title>Caching Name Server</title>
<indexterm>
- <primary>BIND</primary>
- <secondary>caching name server</secondary>
+ <primary>BIND</primary>
+ <secondary>caching name server</secondary>
</indexterm>
<para>A caching name server is a name server that is not
- authoritative for any zones. It simply asks queries of its
- own, and remembers them for later use. To set one up, just
- configure the name server as usual, omitting any inclusions of
- zones.</para>
- </sect2>
-
- <sect2 id="network-named-sandbox">
- <title>Running <application>named</application> in a Sandbox</title>
- <indexterm>
- <primary>BIND</primary>
- <secondary>running in a sandbox</secondary>
- </indexterm>
-
- <indexterm>
- <primary><command>chroot</command></primary>
- </indexterm>
- <para>For added security you may want to run &man.named.8; as an
- unprivileged user, and configure it to &man.chroot.8; into a
- sandbox directory. This makes everything outside of the
- sandbox inaccessible to the <application>named</application>
- daemon. Should <application>named</application> be
- compromised, this will help to reduce the damage that can be
- caused. By default, FreeBSD has a user and a group called
- <groupname>bind</groupname>, intended for this use.</para>
-
- <note><para>Various people would recommend that instead of configuring
- <application>named</application> to <command>chroot</command>, you
- should run <application>named</application> inside a &man.jail.8;.
- This section does not attempt to cover this situation.</para>
- </note>
-
- <para>Since <application>named</application> will not be able to
- access anything outside of the sandbox (such as shared
- libraries, log sockets, and so on), there are a number of steps
- that need to be followed in order to allow
- <application>named</application> to function correctly. In the
- following checklist, it is assumed that the path to the sandbox
- is <filename>/etc/namedb</filename> and that you have made no
- prior modifications to the contents of this directory. Perform
- the following steps as <username>root</username>:</para>
-
- <itemizedlist>
- <listitem>
- <para>Create all directories that <application>named</application>
- expects to see:</para>
-
- <screen>&prompt.root; <userinput>cd /etc/namedb</userinput>
-&prompt.root; <userinput>mkdir -p bin dev etc var/tmp var/run master slave</userinput>
-&prompt.root; <userinput>chown bind:bind slave var/*</userinput><co id="chown-slave"></screen>
-
-
-
- <calloutlist>
- <callout arearefs="chown-slave">
- <para><application>named</application> only needs write access to
- these directories, so that is all we give it.</para>
- </callout>
- </calloutlist>
- </listitem>
-
- <listitem>
- <para>Rearrange and create basic zone and configuration files:</para>
- <screen>&prompt.root; <userinput>cp /etc/localtime etc</userinput><co id="localtime">
-&prompt.root; <userinput>mv named.conf etc && ln -sf etc/named.conf</userinput>
-&prompt.root; <userinput>mv named.root master</userinput>
-<!-- I don't like this next bit -->
-&prompt.root; <userinput>sh make-localhost</userinput>
-&prompt.root; <userinput>cat > master/named.localhost
-$ORIGIN localhost.
-$TTL 6h
-@ IN SOA localhost. postmaster.localhost. (
- 1 ; serial
- 3600 ; refresh
- 1800 ; retry
- 604800 ; expiration
- 3600 ) ; minimum
- IN NS localhost.
- IN A 127.0.0.1
-^D</userinput></screen>
-
- <calloutlist>
- <callout arearefs="localtime">
- <para>This allows <application>named</application> to log the
- correct time to &man.syslogd.8;.</para>
- </callout>
- </calloutlist>
- </listitem>
-
- <listitem>
-
- <indexterm><primary>syslog</primary></indexterm>
- <indexterm><primary>log files</primary>
- <secondary>named</secondary></indexterm>
-
- <para>If you are running a version of &os; prior to 4.9-RELEASE, build a statically linked copy of
- <application>named-xfer</application>, and copy it into the sandbox:</para>
-
- <screen>&prompt.root; <userinput>cd /usr/src/lib/libisc</userinput>
-&prompt.root; <userinput>make cleandir && make cleandir && make depend && make all</userinput>
-&prompt.root; <userinput>cd /usr/src/lib/libbind</userinput>
-&prompt.root; <userinput>make cleandir && make cleandir && make depend && make all</userinput>
-&prompt.root; <userinput>cd /usr/src/libexec/named-xfer</userinput>
-&prompt.root; <userinput>make cleandir && make cleandir && make depend && make NOSHARED=yes all</userinput>
-&prompt.root; <userinput>cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer</userinput><co id="clean-cruft"></screen>
-
- <para>After your statically linked
- <command>named-xfer</command> is installed some cleaning up
- is required, to avoid leaving stale copies of libraries or
- programs in your source tree:</para>
-
- <screen>&prompt.root; <userinput>cd /usr/src/lib/libisc</userinput>
-&prompt.root; <userinput>make cleandir</userinput>
-&prompt.root; <userinput>cd /usr/src/lib/libbind</userinput>
-&prompt.root; <userinput>make cleandir</userinput>
-&prompt.root; <userinput>cd /usr/src/libexec/named-xfer</userinput>
-&prompt.root; <userinput>make cleandir</userinput></screen>
-
- <calloutlist>
- <callout arearefs="clean-cruft">
- <para>This step has been reported to fail occasionally. If this
- happens to you, then issue the command:</para>
-
- <screen>&prompt.root; <userinput>cd /usr/src && make cleandir && make cleandir</userinput></screen>
-
- <para>and delete your <filename>/usr/obj</filename> tree:</para>
-
- <screen>&prompt.root; <userinput>rm -fr /usr/obj && mkdir /usr/obj</userinput></screen>
-
- <para>This will clean out any <quote>cruft</quote> from your
- source tree, and retrying the steps above should then work.</para>
- </callout>
- </calloutlist>
-
- <para>If you are running &os; version 4.9-RELEASE or later,
- then the copy of <command>named-xfer</command> in
- <filename>/usr/libexec</filename> is statically linked by
- default, and you can simply use &man.cp.1; to copy it into
- your sandbox.</para>
- </listitem>
-
- <listitem>
- <para>Make a <filename>dev/null</filename> that
- <application>named</application> can see and write to:</para>
-
- <screen>&prompt.root; <userinput>cd /etc/namedb/dev && mknod null c 2 2</userinput>
-&prompt.root; <userinput>chmod 666 null</userinput></screen>
- </listitem>
-
- <listitem>
- <para>Symlink <filename> /var/run/ndc</filename> to
- <filename>/etc/namedb/var/run/ndc</filename>:</para>
-
- <screen>&prompt.root; <userinput>ln -sf /etc/namedb/var/run/ndc /var/run/ndc</userinput></screen>
-
- <note>
- <para>This simply avoids having to specify the
- <option>-c</option> option to &man.ndc.8; every time you
- run it. Since the contents of
- <filename>/var/run</filename> are deleted on boot, it may
- be useful to add this command to
- <username>root</username>'s &man.crontab.5;, using the
- <option>@reboot</option> option.</para>
- </note>
-
- </listitem>
-
- <listitem>
-
- <indexterm><primary>syslog</primary></indexterm>
- <indexterm><primary>log files</primary>
- <secondary>named</secondary></indexterm>
-
- <para>Configure &man.syslogd.8; to create an extra
- <devicename>log</devicename> socket that
- <application>named</application> can write to. To do this,
- add <literal>-l /etc/namedb/dev/log</literal> to the
- <varname>syslogd_flags</varname> variable in
- <filename>/etc/rc.conf</filename>.</para>
- </listitem>
-
- <listitem>
-
- <indexterm><primary><command>chroot</command></primary></indexterm>
-
- <para>Arrange to have <application>named</application> start
- and <command>chroot</command> itself to the sandbox by
- adding the following to
- <filename>/etc/rc.conf</filename>:</para>
-
- <programlisting>named_enable="YES"
-named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"</programlisting>
-
- <note>
- <para>Note that the configuration file
- <replaceable>/etc/named.conf</replaceable> is denoted by a full
- pathname <emphasis>relative to the sandbox</emphasis>, i.e. in
- the line above, the file referred to is actually
- <filename>/etc/namedb/etc/named.conf</filename>.</para>
- </note>
- </listitem>
- </itemizedlist>
-
- <para>The next step is to edit
- <filename>/etc/namedb/etc/named.conf</filename> so that
- <application>named</application> knows which zones to load and
- where to find them on the disk. There follows a commented
- example (anything not specifically commented here is no
- different from the setup for a DNS server not running in a
- sandbox):</para>
-
- <programlisting>options {
- directory "/";<co id="directory">
- named-xfer "/bin/named-xfer";<co id="named-xfer">
- version ""; // Don't reveal BIND version
- query-source address * port 53;
-};
-// ndc control socket
-controls {
- unix "/var/run/ndc" perm 0600 owner 0 group 0;
-};
-// Zones follow:
-zone "localhost" IN {
- type master;
- file "master/named.localhost";<co id="master">
- allow-transfer { localhost; };
- notify no;
-};
-zone "0.0.127.in-addr.arpa" IN {
- type master;
- file "master/localhost.rev";
- allow-transfer { localhost; };
- notify no;
-};
-zone "." IN {
- type hint;
- file "master/named.root";
-};
-zone "private.example.net" in {
- type master;
- file "master/private.example.net.db";
- allow-transfer { 192.168.10.0/24; };
-};
-zone "10.168.192.in-addr.arpa" in {
- type slave;
- masters { 192.168.10.2; };
- file "slave/192.168.10.db";<co id="slave">
-};</programlisting>
-
- <calloutlist>
- <callout arearefs="directory">
- <para>The
- <literal>directory</literal> statement is specified as
- <filename>/</filename>, since all files that
- <application>named</application> needs are within this
- directory (recall that this is equivalent to a
- <quote>normal</quote> user's
- <filename>/etc/namedb</filename>).</para>
- </callout>
-
- <callout arearefs="named-xfer">
- <para>Specifies the full path
- to the <command>named-xfer</command> binary (from
- <application>named</application>'s frame of reference). This
- is necessary since <application>named</application> is
- compiled to look for <command>named-xfer</command> in
- <filename>/usr/libexec</filename> by default.</para>
- </callout>
- <callout arearefs="master"><para>Specifies the filename (relative
- to the <literal>directory</literal> statement above) where
- <application>named</application> can find the zone file for this
- zone.</para>
- </callout>
- <callout arearefs="slave"><para>Specifies the filename
- (relative to the <literal>directory</literal> statement above)
- where <application>named</application> should write a copy of
- the zone file for this zone after successfully transferring it
- from the master server. This is why we needed to change the
- ownership of the directory <filename>slave</filename> to
- <groupname>bind</groupname> in the setup stages above.</para>
- </callout>
- </calloutlist>
-
- <para>After completing the steps above, either reboot your
- server or restart &man.syslogd.8; and start &man.named.8;, making
- sure to use the new options specified in
- <varname>syslogd_flags</varname> and
- <varname>named_flags</varname>. You should now be running a
- sandboxed copy of <application>named</application>!</para>
-
+ authoritative for any zones. It simply asks queries of its
+ own, and remembers them for later use. To set one up, just
+ configure the name server as usual, omitting any inclusions of
+ zones.</para>
</sect2>
<sect2>
<title>Security</title>
<para>Although BIND is the most common implementation of DNS,
- there is always the issue of security. Possible and
- exploitable security holes are sometimes found.
- </para>
-
- <para>
- It is a good idea to read <ulink
- url="http://www.cert.org/">CERT</ulink>'s security advisories and
- to subscribe to the &a.security-notifications;
- to stay up to date with the current Internet and FreeBSD security
- issues.
+ there is always the issue of security. Possible and exploitable
+ security holes are sometimes found.
</para>
- <tip><para>If a problem arises, keeping sources up to date and
- having a fresh build of <application>named</application> would
- not hurt.</para></tip>
- </sect2>
-
- <sect2>
- <title>Further Reading</title>
-
- <para>BIND/<application>named</application> manual pages:
- &man.ndc.8; &man.named.8; &man.named.conf.5;</para>
-
- <itemizedlist>
- <listitem>
- <para><ulink
- url="http://www.isc.org/products/BIND/">Official ISC BIND
- Page</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink
- url="http://www.nominum.com/getOpenSourceResource.php?id=6">
- BIND FAQ</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly
- DNS and BIND 4th Edition</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink
- url="ftp://ftp.isi.edu/in-notes/rfc1034.txt">RFC1034
- - Domain Names - Concepts and Facilities</ulink></para>
- </listitem>
-
- <listitem>
- <para><ulink
- url="ftp://ftp.isi.edu/in-notes/rfc1035.txt">RFC1035
- - Domain Names - Implementation and Specification</ulink></para>
- </listitem>
- </itemizedlist>
- </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 <application>named</application> currently
- reside in
- <filename class="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 class="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 class="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> file could just be
- copied over into the <filename class="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="domainname">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 <application>named</application> 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 <application>named</application>
- 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 <application>named</application>
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.</para>
+ <para>It is always good idea to read <ulink
+ url="http://www.cert.org/">CERT</ulink>'s security advisories
+ and to subscribe to the &a.security-notifications; to stay up to
+ date with the current Internet and &os; security issues.</para>
+
+ <tip>
+ <para>If a problem arises, keeping sources up to date and
+ having a fresh build of <application>named</application> would
+ not hurt.</para>
+ </tip>
+
<sect3>
<title>Query Access Control Lists</title>
@@ -4125,24 +3724,24 @@
example host, just define it like this:</para>
<programlisting>acl "example.com" {
- 192.168.0.0/24;
+ 192.168.0.0/24;
};
zone "example.com" {
- type slave;
- file "slave/example.com";
- masters {
- 10.0.0.1;
- };
+ 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;
- };
+ type slave;
+ file "slave/0.168.192.in-addr.arpa";
+ masters {
+ 10.0.0.1;
+ };
allow-query { example.com; };
};</programlisting>
</sect3>
@@ -4166,24 +3765,60 @@
<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";
+ 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
+<!-- Here is where Tom stopped for now
<sect3>
- <title>Authentication</title>
+ <title>Authentication</title>
<para> ... </para>
-
-->
</sect2>
- </sect1>
+ <sect2>
+ <title>Further Reading</title>
+
+ <para>BIND/<application>named</application> manual pages:
+ &man.rndc.8; &man.named.8; &man.named.conf.5;</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><ulink
+ url="http://www.isc.org/products/BIND/">Official ISC BIND
+ Page</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink
+ url="http://www.nominum.com/getOpenSourceResource.php?id=6">
+ BIND FAQ</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly
+ DNS and BIND 4th Edition</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink
+ url="ftp://ftp.isi.edu/in-notes/rfc1034.txt">RFC1034
+ - Domain Names - Concepts and Facilities</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para><ulink
+ url="ftp://ftp.isi.edu/in-notes/rfc1035.txt">RFC1035
+ - Domain Names - Implementation and Specification</ulink></para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+ </sect1>
<sect1 id="network-apache">
<sect1info>
More information about the freebsd-doc
mailing list