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

Add section on setting up a DNS server in the Advanced Networking Chapter.

Browse source 
Submitted by:	Chern Lee <chern@osd.bsdi.com>
This commit is contained in:
Murray Stokely 2001-04-14 00:58:57 +00:00
parent 852c0c59ca
commit d56db00760
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=9195
2 changed files with 1284 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

644
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.35 2001/02/09 16:02:02 dannyboy Exp $
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.36 2001/04/09 00:33:48 dd Exp $
-->
<chapter id="advanced-networking">
@ -2703,9 +2703,649 @@ dhcp_flags=""</programlisting>
</sect2>
</sect1>
<sect1 id="dns">
<title>DNS</title>
<para><emphasis>Written by Chern Lee <email>clee@serenivision.com</email>, April 12, 2001.
</emphasis>
</para>
<sect2>
<title>Overview</title>
<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 ips, and vice
versa. For example, a query for www.freebsd.org will send back a reply
for the IP address of The FreeBSD Project's webpage, whereas, a query for
ftp.freebsd.org will return the IP of the corresponding ftp
machine. Likewise, the opposite can happen. A query for an ip address
can resolve its hostname.
</para>
<para>DNS is coordinated across the Internet through a somewhat complex system
of authoritative root name servers, and other smaller-scale nameservers
who host and relay individual domain information.
</para>
<para>
This document refers to BIND 8.x, as it is the most current, stable
version used in FreeBSD.
</para>
<para>
RFC1034 and RFC1035 dictates the DNS protocol.
</para>
<para>
Currently, BIND is maintained by the <ulink url="http://www.isc.org">
Internet Software Consortium (www.isc.org)</ulink>
</para>
</sect2>
<sect2>
<title>Terminology Used</title>
<para><emphasis>zone</emphasis> - Each individual domain, subdomain,
or 'area' dictated by DNS is considered a zone.
</para>
<para>Examples of zones:
</para>
<itemizedlist>
<listitem>
<para>. is the root zone</para>
</listitem>
<listitem>
<para>org. is a zone under the root zone</para>
</listitem>
<listitem>
<para>foobardomain.org is a zone under the org. zone</para>
</listitem>
<listitem>
<para>foo.foobardomain.org. is a subdomain, a zone under the
foobardomain.org. zone
</para>
</listitem>
<listitem>
<para>
1.2.3.in-addr.arpa is a zone referencing all ips which fall under
the 3.2.1.* ip space.
</para>
</listitem>
</itemizedlist>
<para><emphasis>named, bind, name server</emphasis> - these are all common
names for the BIND name server package within FreeBSD.
</para>
<para><emphasis>resolver</emphasis> - a network process by which a system
queries a nameserver for answers
</para>
<para><emphasis>root zone</emphasis> - literally, a '.', refers to the root,
or beginning zone. All zones fall under this, as do all files in fall
under the root directory. It is the beginning of the Internet zone
hierarchy
</para>
<para><emphasis>origin</emphasis> - refers to the point of start for the
particular zone
</para>
<para><emphasis>forward dns</emphasis> - mapping of hostnames to ip addresses
</para>
<para><emphasis>reverse dns</emphasis> - the opposite, mapping of ip
addresses to hostnames
</para>
</sect2>
<sect2>
<title>Reasons to run a name server</title>
<itemizedlist>
<listitem>
<para>
You need your machine to host DNS information to the world
</para>
<itemizedlist>
<listitem>
<para>An authoritative nameserver replies exclusively
to requests.
</para>
</listitem>
<listitem>
<para>For example, you register foobardomain.org and wish to assign
hostnames to its proper ip addresses.
</para>
</listitem>
<listitem>
<para>A slave nameserver, which replies to queries for a
domain when the primary is down or inaccessible.
</para>
</listitem>
<listitem>
<para>The above two can also be done with in-addr.arpa, ip to
hostname entries
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
You wish your machine to act as a local relay of DNS
information
</para>
<itemizedlist>
<listitem>
<para>DNS traffic has been measured to be about 5% or more of
the total Internet traffic.
</para>
</listitem>
<listitem>
<para>A local DNS server may have some added benefit by
providing a local cache of DNS information.
</para>
</listitem>
<listitem>
<para>
For example, when one queries for www.freebsd.org, their
resolver goes out to (usually) your ISP's name server, and
retreives the query.
</para>
</listitem>
<listitem>
<para>
With a local, caching DNS server, the query only has to be
made once to the outside world. Every additional query will
not have to go outside of the local network, since the
information is cached.
</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>How it works</title>
<para>
A DNS server in FreeBSD relies on the BIND daemon. This daemon is
called 'named' for obvious reasons.
</para>
<para><command>named</command> - the bind daemon</para>
<para><command>ndc</command> - name daemon control program</para>
<para>
<filename>/etc/namedb</filename> - directory where all the bind information
resides
</para>
<para>
<filename>/etc/namedb/named.conf</filename> - daemon configuration file
</para>
<para>
zone files are usually contained within the <filename>/etc/namedb</filename>
directory, and contain the information (query answers from your site)
served by your name server.
</para>
</sect2>
<sect2>
<title>Starting BIND</title>
<para>
Since bind is installed by default, configuring it all is relatively
simple.
</para>
<para>
To ensure the named daemon is started at boot, put the following
modifications in your <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>
</sect2>
<sect2>
<title>Configuration files</title>
<sect3>
<title>make-localhost</title>
<para>Be sure to
</para>
<screen>
&prompt.root; <userinput>cd /etc/namedb
&prompt.root; sh make-localhost</userinput>
</screen>
<para>to properly create your local reverse dns zone file in
<filename>/etc/namedb/localhost.rev</filename>.
</para>
</sect3>
<sect3>
<title><filename>/etc/namedb/named.conf</filename></title>
<programlisting>
// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.1 2000/07/15 07:49:29 kris Exp $
//
// Refer to the named(8) man 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.
options {
directory "/etc/namedb";
// 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;
// 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.
/*
forwarders {
127.0.0.1;
};
*/
</programlisting>
<para>
Just as the comment says, if you want to benefit from your uplink's
cache, you can enable this section of the config file.
Normally, your nameserver will recursively query different nameservers
until it finds the answer it is looking for. Having this enabled will
have it automatically see if your uplink's (or whatever provided) ns
has the requested query.
If your uplink has a heavily trafficked, fast nameserver, enabling
this properly could work to your advantage.
127.0.0.1 will *NOT* work here; change this to the ip of a nameserver
at your uplink.
</para>
<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 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";
};
// Note: the following will be supported in a future release.
/*
host { any; } {
topology {
127.0.0.0/8;
};
};
*/
// 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.
// Also, make sure to enable it in /etc/rc.conf.
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
zone
"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.INT" {
type master;
file "localhost.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
// 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
// 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.
//
// 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
/*
zone "domain.com" {
type slave;
file "s/domain.com.bak";
masters {
192.168.1.1;
};
};
zone "0.168.192.in-addr.arpa" {
type slave;
file "s/0.168.192.in-addr.arpa.bak";
masters {
192.168.1.1;
};
};
*/
</programlisting>
<para>
These are example slave entries, read below to see more.
</para>
<para>
For each new domain added to your nameserver, you must add one of
these entries to your <filename>named.conf</filename>
</para>
<para>
The simplest zone entry, can look like
</para>
<programlisting>
zone "foobardomain.org" {
type master;
file "foorbardomain.org";
};
</programlisting>
<para>For a master entry with the zone information within
foobardomain.org, or
</para>
<programlisting>
zone "foobardomain.org" {
type slave;
file "foobardomain.org";
};
</programlisting>
<para>
for a slave. Note that slave zones automatically query the listed
master (authoritative) name servers for the zone file.
</para>
</sect3>
<sect3>
<title>Zone files</title>
<para>
An example master 'foobardomain.org' (existing within
/etc/namedb/foobardomain.org) is as follows:
</para>
<programlisting>
$TTL 3600
foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.org. (
5 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum TTL
; DNS Servers
@ IN NS ns1.foobardomain.org.
@ IN NS ns2.foobardomain.org.
; 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
; Aliases
www IN CNAME @
; MX Record
@ IN MX 10 mail.foobardomain.org.
</programlisting>
<para>
Note that every hostname ending in a '.' is an exact hostname, whereas
everything without a trailing '.' is referenced to the origin. For
example, www is transalated into www + origin. In our ficitious zone
file, our origin is foobardomain.org, so www would be
www.foobardomain.org.
</para>
<para>
The format of this file follows:
</para>
<programlisting>recordname IN recordtype value</programlisting>
<para>
The most commonly used DNS records:
</para>
<para><emphasis>SOA</emphasis> - start of zone authority</para>
<para><emphasis>NS</emphasis> - an authoritative nameserver</para>
<para><emphasis>A</emphasis> - A host address</para>
<para><emphasis>CNAME</emphasis> - the canonical name for an alias</para>
<para><emphasis>MX</emphasis> - mail exchange</para>
<para><emphasis>PTR</emphasis> - a domain name pointer (used in reverse
dns)</para>
<programlisting>
foobardomain.org. IN SOA ns1.foobardomain.org. admin.foobardomain.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>
<para>
<emphasis>foobardomain.org.</emphasis> - the domain name, also the
origin for this zone file.
</para>
<para><emphasis>ns1.foobardomain.org.</emphasis> - the
primary/authoritative nameserver for this zone
</para>
<para><emphasis>admin.foobardomain.org.</emphasis> - the responsible
person for this zone, e-mail address with @ replaced.
(admin@foobardomain.org becomes admin.foobardomain.org)
</para>
<para>
<emphasis>5</emphasis> - the serial number of the file. this must be
incremented each time the zone file is modified. Nowadays, many
admins prefer a yyyymmddrr format for the serial number. 2001041002
would mean last modified 04/10/2001, the latter 02 being the second
time the zone file has been modified this day. The serial number is
important as it alerts slave nameservers for a zone when it is updated.
</para>
<programlisting>
@ IN NS ns1.foobardomain.org.
</programlisting>
<para>
This is an NS entry. Every nameserver that is going to reply
authoritatively for the zone must have one of these entries. The @
is seen here could have been 'foobardomain.org.' The @ transalates 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,
ns1.foobardomain.org would resolve to 3.2.1.2. Again, the origin
symbol, @, is used here, thus meaning foobardomain.org would resolve
to 3.2.1.30.
</para>
<programlisting>
www IN CNAME @
</programlisting>
<para>
The canonical name record is usually used for giving aliases to a
machine. In the example, www is aliased to the machine addressed to
the origin, or foobardomain.org (3.2.1.30). CNAMEs can be used to
provide alias hostnames, or round robin one hostname among multiple
machines.
</para>
<programlisting>
@ IN MX 10 mail.foobardomain.org.
</programlisting>
<para>
The MX record indictes which mail servers are responsible for handling
incoming mail for the zone. mail.foobardomain.org is the hostname of
the mail server, and 10 being the priority of that mailserver.
</para>
<para>
One can have several mailservers, with priorities of 3, 2, 1. A mail
server attempting to deliver to foobardomain.org 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.foobardomain.org. admin.foobardomain.org. (
5 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
3600 ) ; Minimum
@ IN NS ns1.foobardomain.org.
@ IN NS ns2.foobardomain.org.
2 IN PTR ns1.foobardomain.org.
3 IN PTR ns2.foobardomain.org.
10 IN PTR mail.foobardomain.org.
30 IN PTR foobardomain.org.
</programlisting>
<para>
This file gives the proper ip to hostname mappings of our above
ficticious domain.
</para>
</sect3>
</sect2>
<sect2>
<title>Caching Name Server</title>
<para>
A caching nameserver is simply a nameserver 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>
<title>How to use the nameserver</title>
<para>If setup properly, the nameserver should be accessible through the
network and locally. <filename>/etc/resolv.conf</filename> must contain
a nameserver entry with the local ip so it will query the local name
server first.
</para>
<para>
To access it over the network, the machine must have the nameserver's ip
set properly in its own nameserver configuration options.
</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 subscribe to <ulink url="http://www.cert.org">CERT</ulink>
and
<ulink url="http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL">freebsd-announce</ulink>
to stay up to date with the current Internet and FreeBSD security issues.
</para>
<para>
If a problem arises, keeping your sources up to date and having a fresh
build of named can't hurt.
</para>
</sect2>
<sect2>
<title>Further Reading</title>
<para>
&man.ndc.8; &man.named.8; &man.named.conf.5;
</para>
<para>
Official ISC BIND Page
<ulink url="http://www.isc.org/products/BIND/">http://www.isc.org/products/BIND/</ulink>
</para>
<para>
BIND FAQ
<ulink url="http://www.nominum.com/resources/faqs/bind-faqs.html">
http://www.nominum.com/resources/faqs/bind-faqs.html</ulink>
</para>
<para>
<ulink url="http://www.oreilly.com/catalog/dns4/">O'Reilly DNS and BIND 4th Edition</ulink>
</para>
<para>
<ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1034.txt">RFC1034 - Domain Names -
Concepts and Facilities</ulink>
</para>
<para>
<ulink url="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1035.txt">RFC1035 - Domain Names -
Implementation and Specification</ulink>
</para>
</sect2>
</sect1>
</chapter>
<!--
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"