Three advices:
1. Get DNS and BIND book. It's nice to understand how DNS works.
2. DNS needs time to distribute its information.
3. BIND won't load if there is a syntax error.
If you have two or more computers, it is recommended to use DNS
instead of /etc/hosts. Another obvious advantage is mail routing.
With traditional /etc/hosts, there is no easy way to specify backup
mail servers for mail delivery. This howto is based on the author's
experience with BIND on his favourite NetBSD 1.5.1 and 1.5X boxes.
- Download BIND
- Setup zone and DNS records
- Secure BIND
- Different DNS servers
- Run DNS for your own domain
- Familiarize with DNS
tools
Download BIND
NetBSD 1.5.1 comes with BIND 8.2.3 and 8.2.4-REL-NOESW on NetBSD
1.5X. BIND8 is considered to be stable and is used by most root
name servers. BIND9 is a complete rewrite with several new
features:
DNSSEC (signed zones)
TSIG (signed DNS requests)
IPv6 support
Bitstring Labels
DNS Protocol Enhancements
IXFR, DDNS, Notify, EDNS0
Views (former split-dns)
Multiprocessor Support
Improved Portability Architecture
So it is worthwhile to run and play with new features.For the rest
of the howto, BIND means BIND version 9.
Since BIND is in the NetBSD packages collection, first, get the
packages collection then install BIND. You can skip this part and
just download the BIND source from
here and just
build yourself.
Edit an example supfile in /usr/share/examples/supfiles:
# cp /usr/share/examples/supfiles/sup.netbsd.org /etc/ports-supfile
Remove other lines except for the ``current release'' below.
# $NetBSD: sup.netbsd.org,v 1.4.10.1 2000/08/10 23:15:24 soda Exp $
#
# Example supfile for sup.netbsd.org.
#
current release=pkgsrc host=sup.netbsd.org hostbase=/ftp/pub \
base=/usr prefix=/usr backup use-rel-suffix compress delete
Retrieve the packages collection:
# cd /usr
# sup /etc/ports-supfile
( packages downloading, it will take a while. Maybe now is a good time for an
expresso cup... )
...
Once it is done, build and install BIND9 as:
# cd /usr/pkgsrc/net/BIND9
# make install clean
( BIND9 building, installing and cleaning...Another expresso cup would
be nice )
...
BIND binaries will be installed mostly in /usr/pkg/sbin. It also
comes with lwresd and named9 scripts in /usr/pkg/etc/rc.d. Copy
named9 to /etc/rc.d and turn on the executable bit with chmod +x.
# cp /usr/pkg/etc/rc.d/named9 /etc/rc.d
# chmod +x /etc/rc.d/named9
lwresd is the lightweight resident daemon. Not a requirement to get
BIND running. Now, enable BIND on startup:
# vi /etc/rc.conf.d/named9 and add:
named9=YES
named_flags="-c /etc/namedb/named.conf"
This will start BIND as root user in non-chroot compartment.
Section 3 of this howto will change how it runs.
Setup zone and DNS records
For this howto, assume the following ficticious information:
Domain example.com:
host1:
IP: 10.0.0.1
Purpose: primary DNS server
primary mail server
primary web server
host2:
IP: 10.0.0.2
Purpose: secondary DNS server
secondary mail server
host3:
IP: 10.0.0.3
Purpose: secondary DNS server
primary ftp server
network: 10.0.0/24
loopback: 127.0.0.1
BIND configuration files for host1 as primary DNS server:
Configuration directory: /etc/namedb
Main configuration file: named.conf
example.com name-to-address zone: db.example
example.com address-to-name zone: db.10.0.0
loopback zone: db.127.0.0
root hint zone: db.cache
/*
* Main configuration file
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name-to-address zone file */
zone "example.com" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.example";
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.10.0.0";
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com name-to-address zone
* /etc/namedb/db.example
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Mail MX RRs
;
example.com. IN MX 0 host1.example.com.
IN MX 10 host2.example.com.
;
; Addresses for the canonical names
;
localhost IN A 127.0.0.1
host1 IN A 10.0.0.1
host2 IN A 10.0.0.2
host3 IN A 10.0.0.3
;
; Aliases
;
www IN CNAME host1.example.com.
mail IN CNAME host2.example.com.
ftp IN CNAME host3.example.com.
/*
* example.com address-to-name zone
* /etc/namedb/db.10.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Addresses point to canonical name
;
1 IN PTR host1.example.com.
2 IN PTR host2.example.com.
3 IN PTR host3.example.com.
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute
this command to download the latest copy.
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host2 as secondary:
Configuration directory: /etc/namedb
Main configuration file: named.conf
example.com name-to-address zone: secondary for host1
example.com address-to-name zone: secondary for host1
loopback zone: db.127.0.0
root hint zone: db.cache
/*
* BIND configuration file for host2
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name to address zone file */
zone "example.com" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.example";
masters { 10.0.0.1; };
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.10.0.0";
masters { 10.0.0.1; };
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file from
* local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute
this command to download the latest copy.
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host3 as slave:
Configuration directory: /etc/namedb
Main configuration file: named.conf
example.com name-to-address zone: secondary for host1
example.com address-to-name zone: secondary for host1
loopback zone: db.127.0.0
root hint zone: db.cache
From this point on, host3 configuration files are identical to
host2. Just repeat the steps for host2.
Starting BIND:
Before starting BIND on host1, verify that named.conf and zone
files are syntatically correct and valid.
# /usr/pkg/sbin/named-checkconf /etc/namedb/named.conf
# /usr/pkg/sbin/named-checkzone example.com /etc/namedb/db.example
At this point, BIND is ready to start:
# /etc/rc.d/named9 start
Starting named.
#
Check /var/log/messages for the last line for the word "running".
e.g.: Aug 6 16:01:00 roseapple /usr/pkg/sbin/named[8203]: running
Looks like BIND is running on host1. Repeat this step for host2
and host3.
Once all three hosts are up and running, lets put them into use
by editing /etc/resolv.conf and add:
search example.com
nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3
Then ping host2, host3 and localhost from host1 to see if
name-to-address is working. They should resolve to 10.0.0.2,
10.0.0.3 and 127.0.0.1. Try to ping
www.yahoo.com to see if BIND is perusing
root hint zone. Finally, to test reverse mapping, use ``host'' and
give the IP address of host2, 3 and localhost and the output should
look similar to this:
# host 10.0.0.2
2.0.0.10.IN-ADDR.ARPA domain name pointer host2.example.com
Repeat this on host2 and host3. Both should behave the same as
host1. If all goes well, time for a third expresso cup. It is
definitely boring doing all these steps. There is a utility called
h2n which will convert a working /etc/hosts into configuration
files above. However, doing manually is tedious but sure makes your
brain smarter.
Secure BIND
Now that everything is working, there are other considerations to
make it more secure.
Early versions of BIND did not have a good security record.
However, BIND is still the best implementation around.
Obscure BIND version:
Firstly, people have no business in knowing what version of BIND
is running. Secondly, according to the
Project Honeynet, the two most
popular scans from script kiddies on the internet today are BIND
version and portmap (rpcbind). So this is another good reason to
not give them the easy information they need.
In /etc/namedb/named.conf, add a
version statement and
put whatever you want between double quote.
options {
directory "/etc/namedb";
version "Expresso cup";
};
Now, use dig to query the version from a remote host and "Expresso
cup" should appear instead of real BIND version.
# dig @host1.example.com txt chaos version.bind
Restrict zone transfer:
Zone transfer is intended for secondary nameservers to retrieve
any zones for backup purposes. For other nameservers, they should
not be able to retrieve any zones and use whatever information to
mount attacks. Lets restrict zone transfer to trusted secondary
nameservers only.
In
host1, edit /etc/namedb/db.example:
zone "example.com" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
In
host1, edit /etc/namedb/db.10.0.0:
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
Restrict zone transfer on any secondary too as attackers will
try to zone transfer all authoritative dns servers.
Restrict query:
Query is similar to mail open relay concept. Only trusted mail
clients can relay mails through the mail server. With DNS, only
trusted clients can query the server.
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
In
host1, edit /etc/namedb/db.example:
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
In
host1, edit /etc/namedb/db.10.0.0:
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
Restrict recursive query:
Recursive query is a query send to the nameserver for the
information which the local nameserver is not authoritative and
must ask other nameservers for the answer. The answer is then feed
back to the client and the nameserver will cache the information
for future requests. Trusted DNS clients use this feature by
listing nameservers in /etc/resolv.conf. Even if untrusted clients
putting our nameservers in their /etc/resolv.conf and our
nameservers to do the work for free, prevent this from happen with
allow-recursion below.
Restrict recursive query to only trusted DNS clients:
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
options {
directory "/etc/namedb";
version "Expresso cup";
allow-recursion { "example.com-net"; };
};
Run BIND as non-root user inside chroot jail under NetBSD
1.5.1:
Add named account to passwd using vipw:
named:*:14:14::0:0:Named pseudo-user:/var/named:/sbin/nologin
Add named group to /etc/group:
named:*:14:
Populate the chroot compartment:
# mkdir -p /var/chroot/named
# cd /var/chroot/named
# mkdir -p dev etc/namedb/cache usr/libexec var/run var/tmp
# chmod 775 etc/namedb/cache
# chown -R named:named etc/namedb/cache
# chmod 775 var/run
# chmod 01775 var/tmp
# chgrp named var/run var/tmp
# mknod dev/null c 2 2
# mknod dev/random c 46 0
# chmod 666 dev/null dev/random
# chgrp named /etc/rndc.conf /etc/rndc.key
# chmod 640 /etc/rndc.conf /etc/rndc.key
# cp -p /etc/rndc.key /var/chroot/named/etc
Edit BIND startup configuration file so that it will run in chroot
compartment with a non-priviledged user:
Modify /etc/rc.conf.d/named9 and add -u named -t
/var/chroot/named to named_flags:
named9=YES
named_flags="-c /etc/namedb/named.conf -u named -t /var/chroot/named"
Edit BIND script to point from old location of pid-file to new one:
# vi /etc/rc.d/named9
and change:
pidfile="/var/run/${name}.pid"
to:
pidfile="/var/chroot/named/var/run/${name}.pid"
Copy BIND configuration files to chroot compartment and set proper
permission:
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Restart BIND to pick up new changes:
# /etc/rc.d/named9 restart
Run BIND as non-root user inside chroot jail under NetBSD 1.5
current:
On 1.5X current, the chroot jail compartment is already
populated and ready to use. All is needed is to copy the
configuration files in /etc/namedb to
/var/chroot/named/etc/namedb.
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Edit BIND startup config file so that it will run in chroot
compartment with a non-priviledged user:
Modify /etc/rc.conf.d/named9 and add -t /var/chroot/named and -u
named to named_flags:
named9=YES
named_flags="-c /etc/namedb/named.conf -t /var/chroot/named -u named"
Starting with BIND 9.2.0, it requires /dev/random in chroot, so
populate it:
# mknod /var/chroot/named/dev/random c 46 0
If the nameserver is a slave for any other domains, BIND needs to
have write access to that directory.
/var/chroot/named/etc/namedb/cache is where BIND will download
other domain zones. Modify named.conf accordingly for the backup
zones and make sure the ``file'' statement is referring to
``cache'' directory. e.g.:
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "cache/db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
Running rndc to manage BIND in chroot environment requires proper
permission.
Allow group BIND to use rndc in chroot:
# chgrp named /etc/rndc.conf /etc/rndc.key
Only root and group BIND should know the secret key:
# chmod 640 /etc/rndc.conf /etc/rndc.key
Finally, BIND needs to know the secret key when loading:
# cp -p /etc/rndc.key /var/chroot/named/etc
Start BIND in chroot:
# /etc/rc.d/named9 start
Different DNS servers
There are different type of DNS servers each serving a purpose. We
have discussed and configured primary/master, secondary/slave.
Others are cache only server, forwarding server and stealth server.
Lets look at each one of them.
Cache only name server:
Cache only name server basically caches information that it
receives and uses it until the data expires. A cache only server is
not authoritative for any zone.
Here is an example configuration of a cache only server:
/*
* file: /etc/namedb/named.conf
* purpose: cache only name server
*/
acl "example.com.internal" {
192.168.1.0/24;
};
options {
directory "/etc/namedb";
allow-query { "example.com.internal"; };
};
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
Stealth server:
From BIND9 ARM:
A stealth server is a server that answers authoritatively for a
zone, but is not listed in that zone.s NS records. Stealth servers
can be used as a way to centralize distribution of a zone, without
having to edit the zone on a remote nameserver. Where the master
file for a zone resides on a stealth server in this way, it is
often referred to as a ``hidden primary'' configuration. Stealth
servers can also be a way to keep a local copy of a zone for rapid
access to the zone.s records, even if all ``official'' nameservers
for the zone are inaccessible.
Remote name daemon controller: rndc
BIND comes with rndc and is a tool to manage a running BIND. To
use rndc, an /etc/rndc.conf is required. rndc uses an authenticated
link to communicate with the name server. This will reduce the
chance of message spoofing the link.
Get rndc to work:
First, generate a shared secret key. The key will be used by
rndc and named to authenticate each other.
# dnssec-keygen -a hmac-md5 -b 512 -n HOST int-example
will generate:
Kint-example.+157+23209.key
Kint-example.+157+23209.private
the shared secret key is in either file.
# cat Kint-example.+157+23209.key
int-example. IN KEY 512 3 157 xCWxMply6q0NFFTIpL4Qf9qpFtg/DSADFSsdsdfgC9jq11QabdM+QHPaaOJG 9yzlnYp
U0SWtSY10LXds6twdraoRsOA==
The last long string is the shared secret key, copy and and paste
in the secret statement of /etc/rndc.conf. In /etc/rndc.conf, only
options and key statements are required.
/*
* /etc/rndc.conf for example.com
*/
// Key int-example.
key "int-example." {
algorithm "hmac-md5";
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Default server is localhost and key name is int-example.
options {
default-server localhost;
default-key "int-example.";
};
server localhost {
key "int-example."
};
In /etc/namedb/named.conf, declare the key and controls statement
as below to enable the communicating channel.
// Use shared secret key for TSIG and rndc
key "int-example." {
algorithm hmac-md5;
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Allow rndc to connect to 127.0.0.1 on port 953
controls {
inet 127.0.0.1 allow { localhost; } keys { "int-example." ;};
};
To test rndc, try reload /etc/namedb/named.conf file with:
# rndc reload
rndc: reload command successful
#
View /var/log/messages to see if BIND is reloaded successfully.
To view statistics:
# rndc stats
rndc: stats command successful
#
A file /etc/namedb/named.stats is generated for viewing.
TSIG:
TSIG stands for transaction signatures and is for
server-to-server communication. Useful for dynamic update and zone
transfer.
First create a shared secret key for use during zone transfer
between master and slave:
# dnssec-keygen -a hmac-md5 -b 512 -n HOST example-exslave.
Declare the key in /etc/namedb/named.conf:
// Use shared secret key for TSIG and rndc
key "muine-secondary." {
algorithm hmac-md5;
secret"4BQV4cc6JbE5wlMlVr/+HdO2G7qzBZOSxsrpyR5QjSMXqPm37ZIHZc8x LcsIG6XE
MLnzGK+H3NC7I4Xeoc70Jw==";
};
For the the zone you want to permit slave to transfer add:
// All zone transfers to those signed with the example-other key
allow-transfer { key example-other. ;};
At this point, if the local name server receives a message signed
with this key, it can verify the signature. If the signature
succeeds, the response is signed by the same key.
When using shared secret, /etc/namedb/named.conf should not set
to world-readable. Transfering key from one server to another using
ssh is better than telnet. TSIG requires that the clocks be no more
than 5 minutes apart between master-slave because it will timestamp
TSIG record to prevent replay attacks. Make sure your clock is
synchronize properly.
Tell local name server to sign all requests with key if it's the
one who initiates the transaction.
// Sign all requests with key example-other when communicating with 10.10.0.0
server 10.10.0.0 {
keys { example-other. ;};
};
Run DNS for your own domain
If you're one of those people with a static IP address and a
registered domain name, you might want to consider running your own
DNS instead of relying on somebody else.
First, update example.com DNS information at the domain registry
where it was registered so that your new DNS will become the
authoritative nameserver. Second, arrange with a friend to act as
secondary DNS. Alternatively, use free 3rd party like
Secondary.com or
The Public DNS Service. Read
DJB's Third-party
DNS service page for some caveats.
The idea is to ask the domain registry to ``delegate''
example.com domain requests to your own DNS server and find a
backup for the domain just in case your DNS is unreachable.
Here are what the domain registry required to update their DNS
for proper delegation. Note that the information below are
ficticious:
domain to delegate: example.com
primary dns server for example.com: ns.example.com
ns.example.com IP address: 10.0.0.1
secondary dns server for example.com: ns.other.com
ns.other.com IP address: 172.16.0.1
Here is how it is going to look like in the parent/name registry
DNS zone:
;
; Delegate example.com to ns.example.com DNS
;
| Name |
CLASS |
TTL |
TYPE |
RR Data |
| example.com |
86400 |
IN |
NS |
ns.example.com |
|
86400 |
IN |
NS |
ns.other.com |
| ns.example.com |
86400 |
IN |
A |
10.0.0.1 |
| ns.other.com |
86400 |
IN |
A |
10.0.0.2 |
The last 2 lines are called glue records. Glue record is an A
record where the name appears on the right hand side of an NS
record.
Setup example.com zone to answer requests from the
internet:
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 172.16.0.1; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
allow-transfer { 172.16.0.1; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
/* example.com zone name-to-address */
;
; Default Time To Live for records with undefined TTLs
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Mail servers
;
example.com. IN MX 0 ns.example.com.
IN MX 10 ns.other.com.
;
; example.com
;
IN A 10.0.0.1
;
; ns.example.com
;
ns IN A 10.0.0.1
;
; Aliases:
; www.example.com
; ftp.example.com
;
www IN CNAME ns.example.com.
ftp IN CNAME ns.example.com.
/* example.com zone address-to-name */
;
; Default Time To Live for the zone
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Reverse mapping for ns
;
1 IN PTR ns.example.com.
And the usual loopback zone address-to-name...
And the usual root hint zone...
Setup other.com zone to backup for example.com:
other.com will be able to transfer db.example and db.10.0.0 from
example.com primary dns server. For other.com db.other and
db.172.16.0 should have similar entries as example.com's db.example
and db.10.0.0 zone files.
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* other.com zone address-to-name */
zone "0.16.172.IN-ADDR.ARPA" in {
type master;
file "db.172.16.0";
allow-transfer { none; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
Familiarize with DNS tools
DNS debugging tools: host,dig,nslookup,dnswalk,doc
To find out mail exchange for example.com:
# host -t mx example.com
To find out name server for example.com:
# host -t ns example.com
To manually transfer zone example.com:
# dig @ns.example.com AXFR example.com
Use dnswalk to test example.com:
# dnswalk -d example.com.
Use doc to verify that example.com is configured and functioning
correctly:
# doc example.com
doc will produce log.example.com. file with all the information
needed to verify the correctness of example.com
To find out the authors of BIND:
% dig @ns.example.com authors.bind chaos txt
Load balance (round robin):
BIND supports load balancing between 2 or more IP addresses.
Ping postoffice will
; Name TTL CLASS TYPE RR Data
postoffice 300 IN A 10.0.0.2
300 IN A 10.0.0.3
$ ping postoffice
PING postoffice.example.com (10.0.0.2): 56 data bytes
...
1 packets transmitted, 1 packets received, 0.0% packet loss
$ ping postoffice
PING postoffice.example.com (10.0.0.3): 56 data bytes
...
1 packets transmitted, 1 packets received, 0.0% packet loss
The order will be: 10.0.0.2,10.0.0.3 and 10.0.0.3,10.0.0.2 and back
to 10.0.0.2,10.0.0.3 and so on.
Reference
BIND home:
http://www.isc.org/products/BIND/
DNS rfc:
http://www.example.com/rfc/rfc1035.txt/
DNS and BIND bible:
http://www.ora.com/catalog/dns4/
comp.protocols.tcp-ip.domains Frequently Asked Questions
http://www.intac.com/~cdp/cptd-faq/
Name Server Operations Guide for BIND
http://www.irbs.com/bog-4.9.5/
Read BIND Administrator Reference Manual:
http://www.nominum.com/resources/documentation/Bv9ARM.pdf
Mr. DNS questions archive:
http://www.acmebw.com/askmrdns/
http://www.menandmice.com/9000/9300_DNS_Corner.html
DNS Resources Directory:
http://www.dns.net/dnsrd/
DNS implementation by qmail author:
http://cr.yp.to/djbdns.html
Operational guidelines for Root Name Servers.
http://www.muine.org/rfc2870.txt
Common DNS Operational and Configuration Errors
http://www.muine.org/rfc/rfc1912.txt
Selection and Operation of Secondary DNS Servers
http://www.muine.org/rfc/rfc2182.txt
Tools for DNS debugging
http://www.muine.org/rfc/rfc1713.txt
ftp://ftp.uu.net/.vol/1/ip/dns/
Securing an internet name server
http://www.nsiregistry.com/dns/securing_an_internet_name_server.pdf
Running BIND9 in a chroot cage using NetBSD's new startup system
http://www.daemonnews.org/200110/named-chroot.html
