os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

White space clean up from previous commit.

Browse source
This commit is contained in:
Tom Rhodes 2006-05-21 22:19:56 +00:00
parent 1c58931b47
commit 7f2b7cd113
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=27905
1 changed files with 191 additions and 181 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

372
en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml
View file

@ -2943,25 +2943,26 @@ dhcpd_ifaces="dc0"</programlisting>
</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. Our
@ -2969,27 +2970,27 @@ dhcpd_ifaces="dc0"</programlisting>
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, Top Level Domain
(<acronym>TLD</acronym>), and other smaller-scale name servers
which host and cache individual domain information.
</para>
<para><acronym>DNS</acronym> is coordinated across the Internet
through a somewhat complex system of authoritative root, Top
Level Domain (<acronym>TLD</acronym>), and other smaller-scale
name servers which host and cache individual domain
information.</para>
<para>
Currently, BIND is maintained by the
Internet Software Consortium <ulink url="http://www.isc.org/"></ulink>.
</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>
<indexterm><primary>root zone</primary></indexterm>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
<colspec colwidth="1*">
@ -3004,32 +3005,33 @@ dhcpd_ifaces="dc0"</programlisting>
<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>
@ -3037,13 +3039,15 @@ dhcpd_ifaces="dc0"</programlisting>
<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>
@ -3054,40 +3058,40 @@ dhcpd_ifaces="dc0"</programlisting>
<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 Top level Domain
<listitem>
<para><hostid>.</hostid> is the root zone.</para>
</listitem>
<listitem>
<para><hostid>org.</hostid> is a Top Level Domain
(<acronym>TLD</acronym>) under the root zone.</para>
</listitem>
<listitem>
<para><hostid role="domainname">example.org.</hostid> is a
zone under the <hostid>org.</hostid>
<acronym>TLD</acronym>.</para>
</listitem>
<listitem>
<para>
<hostid>1.168.192.in-addr.arpa</hostid> is a zone referencing
all IP addresses which fall under the <hostid
role="ipaddr">192.168.1.*</hostid> IP space.
</para>
</listitem>
</listitem>
<listitem>
<para><hostid role="domainname">example.org.</hostid> is a
zone under the <hostid>org.</hostid>
<acronym>TLD</acronym>.</para>
</listitem>
<listitem>
<para><hostid>1.168.192.in-addr.arpa</hostid> is a zone
referencing all <acronym>IP</acronym> addresses which fall
under the <hostid role="ipaddr">192.168.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>/dev</filename> directory falls within the root, and
so on.</para>
<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,47 +3104,53 @@ dhcpd_ifaces="dc0"</programlisting>
<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 or second name server, called a slave, will
<para>A backup or second name server, called a slave, will
reply to queries.</para>
</listitem>
</listitem>
</itemizedlist>
<para>A caching name server is needed when:</para>
<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>
</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">
@ -3154,8 +3164,8 @@ dhcpd_ifaces="dc0"</programlisting>
<tbody>
<row>
<entry><application>named</application></entry>
<entry>the BIND daemon</entry>
<entry>&man.named.8;</entry>
<entry>The BIND daemon.</entry>
</row>
<row>
@ -3164,13 +3174,13 @@ dhcpd_ifaces="dc0"</programlisting>
</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 of the daemon.</entry>
</row>
</tbody>
</tgroup>
@ -3189,13 +3199,12 @@ dhcpd_ifaces="dc0"</programlisting>
<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>Since BIND is installed by default, configuring it all is
relatively simple.</para>
<para>The default <application>named</application> configuration
is that of a basic resolving name server, ran in a
@ -3204,11 +3213,10 @@ dhcpd_ifaces="dc0"</programlisting>
<screen>&prompt.root; <userinput>/etc/rc.d/named forcestart</userinput></screen>
<para>
To ensure the <application>named</application> daemon is
<para>To ensure the <application>named</application> daemon is
started at boot each time, put the following line into the
<filename>/etc/rc.conf</filename>:
</para>
<filename>/etc/rc.conf</filename>:</para>
<programlisting>named_enable="YES"</programlisting>
<para>There are obviously many configuration options for
@ -3225,7 +3233,7 @@ dhcpd_ifaces="dc0"</programlisting>
<sect2>
<title>Configuration Files</title>
<indexterm>
<primary>BIND</primary>
<primary>BIND</primary>
<secondary>configuration files</secondary>
</indexterm>
@ -3237,7 +3245,7 @@ dhcpd_ifaces="dc0"</programlisting>
be performed.</para>
<sect3>
<title>Using <command>make-localhost</command></title>
<title>Using <command>make-localhost</command></title>
<para>To configure a master zone for the localhost visit the
<filename role="directory">/etc/namedb</filename> directory
@ -3255,9 +3263,9 @@ dhcpd_ifaces="dc0"</programlisting>
</sect3>
<sect3>
<title><filename>/etc/namedb/named.conf</filename></title>
<title><filename>/etc/namedb/named.conf</filename></title>
<programlisting>// &dollar;FreeBSD$
<programlisting>// &dollar;FreeBSD&dollar;
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
@ -3268,7 +3276,7 @@ dhcpd_ifaces="dc0"</programlisting>
// 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";
@ -3287,56 +3295,56 @@ options {
// 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>
<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>
<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 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 versions 8 and later
<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;
*/
// query-source address * port 53;
};
// 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 "master/localhost.rev";
type master;
file "master/localhost.rev";
};
// RFC 3152
@ -3367,7 +3375,7 @@ 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"
/* An example master zone
zone "example.net" {
type master;
file "master/example.net";
file "master/example.net";
};
*/
@ -3400,63 +3408,66 @@ zone "1.168.192.in-addr.arpa" {
192.168.1.1;
};
};
*/</programlisting>
<para>In <filename>named.conf</filename>, these are examples of slave
entries for a forward and reverse zone.</para>
*/</programlisting>
<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 "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/master/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 "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>
<title>Zone Files</title>
<indexterm>
<primary>BIND</primary>
<secondary>zone files</secondary>
</indexterm>
<para>
An example master zone file for <hostid
<para>An example master zone file for <hostid
role="domainname">example.org</hostid> (existing within
<filename>/etc/namedb/master/example.org</filename>) is as follows:
</para>
<filename>/etc/namedb/master/example.org</filename>) is as
follows:</para>
<programlisting>$TTL 3600
example.org. IN SOA ns1.example.org. admin.example.org. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum TTL
<programlisting>&dollar;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.
@ -3704,17 +3715,16 @@ www IN CNAME localhost</programlisting>
place which could help to lure off possible
<acronym>DNS</acronym> service attacks.</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.
</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>
<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>
@ -3738,8 +3748,8 @@ www IN CNAME localhost</programlisting>
<listitem>
<para><ulink
url="http://www.nominum.com/getOpenSourceResource.php?id=6">
BIND FAQ</ulink></para>
url="http://www.nominum.com/getOpenSourceResource.php?id=6">
BIND FAQ</ulink></para>
</listitem>
<listitem>