diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
index 6cde4ef3a6..cd443d65b5 100644
--- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,7 +1,7 @@
@@ -2703,9 +2703,649 @@ dhcp_flags=""
+
+DNS
+Written by Chern Lee clee@serenivision.com, April 12, 2001.
+
+
+
+
+ Overview
+ 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.
+
+
+ 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.
+
+
+
+ This document refers to BIND 8.x, as it is the most current, stable
+ version used in FreeBSD.
+
+
+
+ RFC1034 and RFC1035 dictates the DNS protocol.
+
+
+
+ Currently, BIND is maintained by the
+ Internet Software Consortium (www.isc.org)
+
+
+
+
+ Terminology Used
+
+ zone - Each individual domain, subdomain,
+ or 'area' dictated by DNS is considered a zone.
+
+
+ Examples of zones:
+
+
+
+ . is the root zone
+
+
+ org. is a zone under the root zone
+
+
+ foobardomain.org is a zone under the org. zone
+
+
+ foo.foobardomain.org. is a subdomain, a zone under the
+ foobardomain.org. zone
+
+
+
+
+ 1.2.3.in-addr.arpa is a zone referencing all ips which fall under
+ the 3.2.1.* ip space.
+
+
+
+
+ named, bind, name server - these are all common
+ names for the BIND name server package within FreeBSD.
+
+
+ resolver - a network process by which a system
+ queries a nameserver for answers
+
+
+ root zone - 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
+
+
+ origin - refers to the point of start for the
+ particular zone
+
+
+ forward dns - mapping of hostnames to ip addresses
+
+
+ reverse dns - the opposite, mapping of ip
+ addresses to hostnames
+
+
+
+
+ Reasons to run a name server
+
+
+
+ You need your machine to host DNS information to the world
+
+
+
+ An authoritative nameserver replies exclusively
+ to requests.
+
+
+
+ For example, you register foobardomain.org and wish to assign
+ hostnames to its proper ip addresses.
+
+
+
+ A slave nameserver, which replies to queries for a
+ domain when the primary is down or inaccessible.
+
+
+
+ The above two can also be done with in-addr.arpa, ip to
+ hostname entries
+
+
+
+
+
+
+ You wish your machine to act as a local relay of DNS
+ information
+
+
+
+ DNS traffic has been measured to be about 5% or more of
+ the total Internet traffic.
+
+
+
+ A local DNS server may have some added benefit by
+ providing a local cache of DNS information.
+
+
+
+
+ For example, when one queries for www.freebsd.org, their
+ resolver goes out to (usually) your ISP's name server, and
+ retreives the query.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+How it works
+
+ A DNS server in FreeBSD relies on the BIND daemon. This daemon is
+ called 'named' for obvious reasons.
+
+
+ named - the bind daemon
+ ndc - name daemon control program
+
+
+ /etc/namedb - directory where all the bind information
+ resides
+
+
+ /etc/namedb/named.conf - daemon configuration file
+
+
+
+ zone files are usually contained within the /etc/namedb
+ directory, and contain the information (query answers from your site)
+ served by your name server.
+
+
+
+
+ Starting BIND
+
+ Since bind is installed by default, configuring it all is relatively
+ simple.
+
+
+ To ensure the named daemon is started at boot, put the following
+ modifications in your /etc/rc.conf
+
+ named_enable="YES"
+ To start the daemon manually (after configuring it)
+ &prompt.root; ndc start
+
+
+
+ Configuration files
+
+ make-localhost
+ Be sure to
+
+
+ &prompt.root; cd /etc/namedb
+ &prompt.root; sh make-localhost
+
+ to properly create your local reverse dns zone file in
+ /etc/namedb/localhost.rev.
+
+
+
+
+ <filename>/etc/namedb/named.conf</filename>
+
+
+// $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;
+ };
+*/
+
+
+
+ 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.
+
+
+
+ /*
+ * 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;
+ };
+};
+*/
+
+
+ These are example slave entries, read below to see more.
+
+
+ For each new domain added to your nameserver, you must add one of
+ these entries to your named.conf
+
+
+ The simplest zone entry, can look like
+
+
+zone "foobardomain.org" {
+ type master;
+ file "foorbardomain.org";
+};
+
+
+ For a master entry with the zone information within
+ foobardomain.org, or
+
+
+
+zone "foobardomain.org" {
+ type slave;
+ file "foobardomain.org";
+};
+
+
+
+ for a slave. Note that slave zones automatically query the listed
+ master (authoritative) name servers for the zone file.
+
+
+
+
+ Zone files
+
+ An example master 'foobardomain.org' (existing within
+ /etc/namedb/foobardomain.org) is as follows:
+
+
+
+$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.
+
+
+
+ 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.
+
+
+
+ The format of this file follows:
+
+ recordname IN recordtype value
+
+
+ The most commonly used DNS records:
+
+ SOA - start of zone authority
+ NS - an authoritative nameserver
+ A - A host address
+ CNAME - the canonical name for an alias
+ MX - mail exchange
+ PTR - a domain name pointer (used in reverse
+ dns)
+
+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
+
+
+ foobardomain.org. - the domain name, also the
+ origin for this zone file.
+
+ ns1.foobardomain.org. - the
+ primary/authoritative nameserver for this zone
+
+ admin.foobardomain.org. - the responsible
+ person for this zone, e-mail address with @ replaced.
+ (admin@foobardomain.org becomes admin.foobardomain.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 nameservers for a zone when it is updated.
+
+
+
+@ IN NS ns1.foobardomain.org.
+
+
+ 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.
+
+
+
+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.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.
+
+
+
+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 foobardomain.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.foobardomain.org.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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.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.
+
+
+ This file gives the proper ip to hostname mappings of our above
+ ficticious domain.
+
+
+
+
+
+ Caching Name Server
+
+ 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.
+
+
+
+
+ How to use the nameserver
+
+ If setup properly, the nameserver should be accessible through the
+ network and locally. /etc/resolv.conf must contain
+ a nameserver entry with the local ip so it will query the local name
+ server first.
+
+
+
+ To access it over the network, the machine must have the nameserver's ip
+ set properly in its own nameserver configuration options.
+
+
+
+
+ Security
+
+ 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 subscribe to CERT
+ and
+ freebsd-announce
+ to stay up to date with the current Internet and FreeBSD security issues.
+
+
+
+ If a problem arises, keeping your sources up to date and having a fresh
+ build of named can't hurt.
+
+
+
+
+ Further Reading
+
+ &man.ndc.8; &man.named.8; &man.named.conf.5;
+
+
+
+ Official ISC BIND Page
+ http://www.isc.org/products/BIND/
+
+
+
+ BIND FAQ
+
+ http://www.nominum.com/resources/faqs/bind-faqs.html
+
+
+
+ O'Reilly DNS and BIND 4th Edition
+
+
+
+ RFC1034 - Domain Names -
+ Concepts and Facilities
+
+
+
+ RFC1035 - Domain Names -
+ Implementation and Specification
+
+
+
+
+
-
@@ -2703,9 +2703,649 @@ dhcp_flags=""
+
+DNS
+Written by Chern Lee clee@serenivision.com, April 12, 2001.
+
+
+
+
+ Overview
+ 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.
+
+
+ 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.
+
+
+
+ This document refers to BIND 8.x, as it is the most current, stable
+ version used in FreeBSD.
+
+
+
+ RFC1034 and RFC1035 dictates the DNS protocol.
+
+
+
+ Currently, BIND is maintained by the
+ Internet Software Consortium (www.isc.org)
+
+
+
+
+ Terminology Used
+
+ zone - Each individual domain, subdomain,
+ or 'area' dictated by DNS is considered a zone.
+
+
+ Examples of zones:
+
+
+
+ . is the root zone
+
+
+ org. is a zone under the root zone
+
+
+ foobardomain.org is a zone under the org. zone
+
+
+ foo.foobardomain.org. is a subdomain, a zone under the
+ foobardomain.org. zone
+
+
+
+
+ 1.2.3.in-addr.arpa is a zone referencing all ips which fall under
+ the 3.2.1.* ip space.
+
+
+
+
+ named, bind, name server - these are all common
+ names for the BIND name server package within FreeBSD.
+
+
+ resolver - a network process by which a system
+ queries a nameserver for answers
+
+
+ root zone - 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
+
+
+ origin - refers to the point of start for the
+ particular zone
+
+
+ forward dns - mapping of hostnames to ip addresses
+
+
+ reverse dns - the opposite, mapping of ip
+ addresses to hostnames
+
+
+
+
+ Reasons to run a name server
+
+
+
+ You need your machine to host DNS information to the world
+
+
+
+ An authoritative nameserver replies exclusively
+ to requests.
+
+
+
+ For example, you register foobardomain.org and wish to assign
+ hostnames to its proper ip addresses.
+
+
+
+ A slave nameserver, which replies to queries for a
+ domain when the primary is down or inaccessible.
+
+
+
+ The above two can also be done with in-addr.arpa, ip to
+ hostname entries
+
+
+
+
+
+
+ You wish your machine to act as a local relay of DNS
+ information
+
+
+
+ DNS traffic has been measured to be about 5% or more of
+ the total Internet traffic.
+
+
+
+ A local DNS server may have some added benefit by
+ providing a local cache of DNS information.
+
+
+
+
+ For example, when one queries for www.freebsd.org, their
+ resolver goes out to (usually) your ISP's name server, and
+ retreives the query.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+How it works
+
+ A DNS server in FreeBSD relies on the BIND daemon. This daemon is
+ called 'named' for obvious reasons.
+
+
+ named - the bind daemon
+ ndc - name daemon control program
+
+
+ /etc/namedb - directory where all the bind information
+ resides
+
+
+ /etc/namedb/named.conf - daemon configuration file
+
+
+
+ zone files are usually contained within the /etc/namedb
+ directory, and contain the information (query answers from your site)
+ served by your name server.
+
+
+
+
+ Starting BIND
+
+ Since bind is installed by default, configuring it all is relatively
+ simple.
+
+
+ To ensure the named daemon is started at boot, put the following
+ modifications in your /etc/rc.conf
+
+ named_enable="YES"
+ To start the daemon manually (after configuring it)
+ &prompt.root; ndc start
+
+
+
+ Configuration files
+
+ make-localhost
+ Be sure to
+
+
+ &prompt.root; cd /etc/namedb
+ &prompt.root; sh make-localhost
+
+ to properly create your local reverse dns zone file in
+ /etc/namedb/localhost.rev.
+
+
+
+
+ <filename>/etc/namedb/named.conf</filename>
+
+
+// $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;
+ };
+*/
+
+
+
+ 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.
+
+
+
+ /*
+ * 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;
+ };
+};
+*/
+
+
+ These are example slave entries, read below to see more.
+
+
+ For each new domain added to your nameserver, you must add one of
+ these entries to your named.conf
+
+
+ The simplest zone entry, can look like
+
+
+zone "foobardomain.org" {
+ type master;
+ file "foorbardomain.org";
+};
+
+
+ For a master entry with the zone information within
+ foobardomain.org, or
+
+
+
+zone "foobardomain.org" {
+ type slave;
+ file "foobardomain.org";
+};
+
+
+
+ for a slave. Note that slave zones automatically query the listed
+ master (authoritative) name servers for the zone file.
+
+
+
+
+ Zone files
+
+ An example master 'foobardomain.org' (existing within
+ /etc/namedb/foobardomain.org) is as follows:
+
+
+
+$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.
+
+
+
+ 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.
+
+
+
+ The format of this file follows:
+
+ recordname IN recordtype value
+
+
+ The most commonly used DNS records:
+
+ SOA - start of zone authority
+ NS - an authoritative nameserver
+ A - A host address
+ CNAME - the canonical name for an alias
+ MX - mail exchange
+ PTR - a domain name pointer (used in reverse
+ dns)
+
+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
+
+
+ foobardomain.org. - the domain name, also the
+ origin for this zone file.
+
+ ns1.foobardomain.org. - the
+ primary/authoritative nameserver for this zone
+
+ admin.foobardomain.org. - the responsible
+ person for this zone, e-mail address with @ replaced.
+ (admin@foobardomain.org becomes admin.foobardomain.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 nameservers for a zone when it is updated.
+
+
+
+@ IN NS ns1.foobardomain.org.
+
+
+ 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.
+
+
+
+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.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.
+
+
+
+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 foobardomain.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.foobardomain.org.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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.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.
+
+
+ This file gives the proper ip to hostname mappings of our above
+ ficticious domain.
+
+
+
+
+
+ Caching Name Server
+
+ 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.
+
+
+
+
+ How to use the nameserver
+
+ If setup properly, the nameserver should be accessible through the
+ network and locally. /etc/resolv.conf must contain
+ a nameserver entry with the local ip so it will query the local name
+ server first.
+
+
+
+ To access it over the network, the machine must have the nameserver's ip
+ set properly in its own nameserver configuration options.
+
+
+
+
+ Security
+
+ 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 subscribe to CERT
+ and
+ freebsd-announce
+ to stay up to date with the current Internet and FreeBSD security issues.
+
+
+
+ If a problem arises, keeping your sources up to date and having a fresh
+ build of named can't hurt.
+
+
+
+
+ Further Reading
+
+ &man.ndc.8; &man.named.8; &man.named.conf.5;
+
+
+
+ Official ISC BIND Page
+ http://www.isc.org/products/BIND/
+
+
+
+ BIND FAQ
+
+ http://www.nominum.com/resources/faqs/bind-faqs.html
+
+
+
+ O'Reilly DNS and BIND 4th Edition
+
+
+
+ RFC1034 - Domain Names -
+ Concepts and Facilities
+
+
+
+ RFC1035 - Domain Names -
+ Implementation and Specification
+
+
+
+
+
-