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 www.FreeBSD.org
will
receive a reply with the IP address of The FreeBSD Project's
web server, whereas, a query for ftp.FreeBSD.org
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.
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.
This document refers to BIND 8.x, as it is the stable version used in FreeBSD. Versions of FreeBSD 5.3 and beyond include BIND9 and the configuration instructions may be found later in this chapter. Users of FreeBSD 5.2 and other previous versions may install BIND9 from the net/bind9 port.
RFC1034 and RFC1035 dictate the DNS protocol.
Currently, BIND is maintained by the
Internet Software Consortium http://www.isc.org/
.
To understand this document, some terms related to DNS must be understood.
Term | Definition |
---|---|
Forward DNS | Mapping of hostnames to IP addresses |
Origin | Refers to the domain covered in a particular zone file |
named, BIND, name server | Common names for the BIND name server package within FreeBSD |
Resolver | A system process through which a machine queries a name server for zone information |
Reverse DNS | The opposite of forward DNS; mapping of IP addresses to hostnames |
Root zone | 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. |
Zone | An individual domain, subdomain, or portion of the DNS administered by the same authority |
Examples of zones:
.
is the root zone
org.
is a zone under the root zone
example.org.
is a
zone under the org.
zone
foo.example.org.
is
a subdomain, a zone under the example.org.
zone
1.2.3.in-addr.arpa
is a zone referencing
all IP addresses which fall under the 3.2.1.*
IP space.
As one can see, the more specific part of a hostname
appears to its left. For example, example.org.
is more specific than
org.
, as org.
is more
specific than the root zone. The layout of each part of a
hostname is much like a file system: the
/dev
directory falls within the root, and
so on.
Name servers usually come in two forms: an authoritative name server, and a caching name server.
An authoritative name server is needed when:
one wants to serve DNS information to the world, replying authoritatively to queries.
a domain, such as example.org
, is
registered and IP addresses need to be assigned to hostnames
under it.
an IP address block requires reverse DNS entries (IP to hostname).
a backup name server, called a slave, must reply to queries when the primary is down or inaccessible.
A caching name server is needed when:
a local DNS server may cache and respond more quickly than querying an outside name server.
a reduction in overall network traffic is desired (DNS traffic has been measured to account for 5% or more of total Internet traffic).
When one queries for www.FreeBSD.org
, 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
locally.
In FreeBSD, the BIND daemon is called named for obvious reasons.
File | Description |
---|---|
named | the BIND daemon |
ndc | name daemon control program |
/etc/namedb | directory where BIND zone information resides |
/etc/namedb/named.conf | daemon configuration file |
Zone files are usually contained within the
/etc/namedb
directory, and contain the DNS zone information
served by the name server.
Since BIND is installed by default, configuring it all is relatively simple.
To ensure the named daemon is
started at boot, put the following line in
/etc/rc.conf
:
named_enable="YES"
To start the daemon manually (after configuring it):
#
ndc start
Be sure to:
#
cd /etc/namedb
#
sh make-localhost
to properly create the local reverse DNS zone file in
/etc/namedb/master/localhost.rev
.
// $FreeBSD$ // // 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. 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; }; */
Just as the comment says, to benefit from an uplink's cache,
forwarders
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.
127.0.0.1
will not work here.
Change this IP address to a name server at your uplink.
/* * 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"; }; // 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"; }; // 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
For more information on running BIND in a sandbox, see Running named in a sandbox.
/* zone "example.com" { type slave; file "s/example.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; }; }; */
In named.conf
, these are examples of slave
entries for a forward and reverse zone.
For each new zone served, a new zone entry must be added to
named.conf
.
For example, the simplest zone entry for
example.org
can look like:
zone "example.org" { type master; file "example.org"; };
The zone is a master, as indicated by the type
statement, holding its zone information in
/etc/namedb/example.org
indicated by
the file
statement.
zone "example.org" { type slave; file "example.org"; };
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.
An example master zone file for example.org
(existing within
/etc/namedb/example.org
) is as follows:
$TTL 3600 example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.example.org. @ IN NS ns2.example.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.example.org.
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 translated into
www.origin
.
In our fictitious zone file, our origin is
example.org.
, so www
would translate to www.example.org.
The format of a zone file follows:
recordname IN recordtype value
The most commonly used DNS records:
start of zone authority
an authoritative name server
a host address
the canonical name for an alias
mail exchanger
a domain name pointer (used in reverse DNS)
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
example.org.
the domain name, also the origin for this zone file.
ns1.example.org.
the primary/authoritative name server for this zone.
admin.example.org.
the responsible person for this zone,
email address with “@”
replaced. (<admin@example.org>
becomes
admin.example.org
)
5
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 name servers for a
zone when it is updated.
@ IN NS ns1.example.org.
This is an NS entry. Every name server that is going to reply
authoritatively for the zone must have one of these entries.
The @
as seen here could have been
example.org.
The @
translates to the origin.
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
The A record indicates machine names. As seen above,
ns1.example.org
would resolve
to 3.2.1.2
. Again, the
origin symbol, @
, is used here, thus
meaning example.org
would
resolve to 3.2.1.30
.
www IN CNAME @
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
example.org
(3.2.1.30
).
CNAMEs can be used to provide alias
hostnames, or round robin one hostname among multiple
machines.
@ IN MX 10 mail.example.org.
The MX record indicates which mail
servers are responsible for handling incoming mail for the
zone. mail.example.org
is the
hostname of the mail server, and 10 being the priority of
that mail server.
One can have several mail servers, with priorities of 3, 2,
1. A mail server attempting to deliver to example.org
would first try the
highest priority MX, then the second highest, etc, until the
mail can be properly delivered.
For in-addr.arpa zone files (reverse DNS), the same format is used, except with PTR entries instead of A or CNAME.
$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.
This file gives the proper IP address to hostname mappings of our above fictitious domain.
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.
For added security you may want to run named(8) as an
unprivileged user, and configure it to chroot(8) into a
sandbox directory. This makes everything outside of the
sandbox inaccessible to the named
daemon. Should named be
compromised, this will help to reduce the damage that can be
caused. By default, FreeBSD has a user and a group called
bind
, intended for this use.
Various people would recommend that instead of configuring
named to chroot
, you
should run named inside a jail(8).
This section does not attempt to cover this situation.
Since named 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
named to function correctly. In the
following checklist, it is assumed that the path to the sandbox
is /etc/namedb
and that you have made no
prior modifications to the contents of this directory. Perform
the following steps as root
:
Create all directories that named expects to see:
#
cd /etc/namedb
#
mkdir -p bin dev etc var/tmp var/run master slave
#
chown bind:bind slave var/*
Rearrange and create basic zone and configuration files:
#
cp /etc/localtime etc
![]()
#
mv named.conf etc && ln -sf etc/named.conf
#
mv named.root master
#
sh make-localhost
#
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
This allows named to log the correct time to syslogd(8). |
If you are running a version of FreeBSD prior to 4.9-RELEASE, build a statically linked copy of named-xfer, and copy it into the sandbox:
#
cd /usr/src/lib/libisc
#
make cleandir && make cleandir && make depend && make all
#
cd /usr/src/lib/libbind
#
make cleandir && make cleandir && make depend && make all
#
cd /usr/src/libexec/named-xfer
#
make cleandir && make cleandir && make depend && make NOSHARED=yes all
#
cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
After your statically linked
named-xfer
is installed some cleaning up
is required, to avoid leaving stale copies of libraries or
programs in your source tree:
#
cd /usr/src/lib/libisc
#
make cleandir
#
cd /usr/src/lib/libbind
#
make cleandir
#
cd /usr/src/libexec/named-xfer
#
make cleandir
This step has been reported to fail occasionally. If this happens to you, then issue the command:
and delete your
This will clean out any “cruft” from your source tree, and retrying the steps above should then work. |
If you are running FreeBSD version 4.9-RELEASE or later,
then the copy of named-xfer
in
/usr/libexec
is statically linked by
default, and you can simply use cp(1) to copy it into
your sandbox.
Make a dev/null
that
named can see and write to:
#
cd /etc/namedb/dev && mknod null c 2 2
#
chmod 666 null
Symlink /var/run/ndc
to
/etc/namedb/var/run/ndc
:
#
ln -sf /etc/namedb/var/run/ndc /var/run/ndc
This simply avoids having to specify the
-c
option to ndc(8) every time you
run it. Since the contents of
/var/run
are deleted on boot, it may
be useful to add this command to
root
's crontab(5), using the
@reboot
option.
Configure syslogd(8) to create an extra
log
socket that
named can write to. To do this,
add -l /etc/namedb/dev/log
to the
syslogd_flags
variable in
/etc/rc.conf
.
Arrange to have named start
and chroot
itself to the sandbox by
adding the following to
/etc/rc.conf
:
named_enable="YES" named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
Note that the configuration file
/etc/named.conf
is denoted by a full
pathname relative to the sandbox, i.e. in
the line above, the file referred to is actually
/etc/namedb/etc/named.conf
.
The next step is to edit
/etc/namedb/etc/named.conf
so that
named 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):
options { directory "/";named-xfer "/bin/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";
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";
};
The
| |
Specifies the full path
to the | |
Specifies the filename (relative
to the | |
Specifies the filename
(relative to the |
After completing the steps above, either reboot your
server or restart syslogd(8) and start named(8), making
sure to use the new options specified in
syslogd_flags
and
named_flags
. You should now be running a
sandboxed copy of named!
Although BIND is the most common implementation of DNS, there is always the issue of security. Possible and exploitable security holes are sometimes found.
It is a good idea to read CERT's security advisories and to subscribe to the FreeBSD security notifications 郵遞論壇 to stay up to date with the current Internet and FreeBSD security issues.
If a problem arises, keeping sources up to date and having a fresh build of named would not hurt.
BIND/named manual pages: ndc(8) named(8) named.conf(5)
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.