[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ next ]
author: Ivan E. Moore II [email protected]
Welcome. The purpose of this section is to help you setup BIND on Debian. The document will start you out from ground zero to an actually working fully functional BIND system. As requested by some people, I will include instructions on how to setup a working DNS Domain from both a Primary Server standpoint and a Secondary Server standpoint.
I am also going to just focus on BIND 9.x since that is the latest version being used by Debian. If you are using BIND 4.x I would recommend you to upgrade.
Please note that most people do not need BIND installed on their system. In fact pretty much only servers really need it. From time to time exploits come out that will do anywhere from denial of service attacks to actual root compromises. Most DNS servers are setup improperly and lead to this. If you are setting up a home system you most likely do not need BIND installed. Please think it over before you proceed.
NOTE: Version 8.2.1 of bind and higher have a different layout. All bind related configuration files are now in /etc/bind. These include the zone files.
Please see Obtaining Help With BIND, Section 8.7 for advanced help with BIND.
Fist off you need to install the proper files. Go into dselect and install the following files:
Required Files:
bind9
dnsutils
Optional Files:
bind9-doc
bind9-host
libbind-dev
dns-browse
libnet-dns-perl
nslint
dhcp-dns
dnscvsutil
If you use apt-get, then just run this command:
apt-get install bind9 bind9-doc dnsutils
If you have already installed bind and answered the questions during install you can go back and reconfigure the base BIND system by typing bindconfig. This program does just the generic basic settings. bindconfig is what dpkg runs when it installs BIND so what I'm about to cover is exactly what you'll go through when you first install BIND. This is what it looks like.
This program doesn't exist in bind versions 8.2.1 and higher. It may show up again sometime, but for now ignore these steps if your using these versions.
snowcrash:/var/named# bindconfig
It appears that you already have an /etc/named.conf file, suggesting
that you have already configured BIND version 8.X at least once. If
you proceed, a copy of this file will be saved, but no customizations
that you have made to it will be included in the new configuration.
If this means nothing to you, go ahead and proceed with the remainder
of the configuration process. If you have customized /etc/named.conf,
you probably want to stop now to preserve your customizations.
Proceed to configure BIND, ignoring existing /etc/named.conf? [N]
BIND Configuration
------------------
By answering the following questions, you can configure BIND for your system.
If your system has already been configured, the default values will allow you
to verify your existing configuration.
Press [ENTER]
Forwarder Hosts
---------------
If you are close to a well-connected host or set of hosts which accept
recursive DNS queries, it would be to your advantage to use them as forwarders
in order to reduce traffic over links to outside servers.
Your DNS server will send all queries not in its cache to the forwarders
first. Each forwarder will be asked in turn until an answer is returned or the
list is exhausted. If no answer is forthcoming from a forwarder, the server
will continue as it would have without the forwarders.
To answer this question, separate each address with a space, or answer `none'
to eliminate all forwarder hosts.
Forwarder IP addresses? []
This option allows you to forward any DNS requests to another DNS server. The reason you might want to do this is if your inside a firewall and cannot directly reach the outside world. You can point your server to do all it's lookups from specific servers inside your network which can reach the outside world.
Localhost Entries
-----------------
With this option, BIND will contain entries for the `localhost' pseudo-host
and its reverse mapping (127.0.0.1). This is recommended.
Enable localhost entries? [Y]
You want this. This allows mapping to and from your localhost which is 127.0.0.1.
Configuration Complete
----------------------
Advanced configuration, such as sortlists, xfrnets, limits, and other options
can be accomplished by manually editing the /var/named/boot.options
configuration file and reloading your nameserver. You may wish to refer to
the named(8) man page or review the documentation in /usr/doc/net/named to
assist in further customization.
This automatic configuration does not manipulate zone files; you should ensure
the proper boot entries are made in /var/named/boot.zones for each primary and
secondary zone you are serving. If you leave this file empty, your server will
act conveniently as a caching-only name server.
Saving old /var/named/boot.options to /var/named/boot.options.old ...
Reading boot.zones ...
Reading boot.options ...
Rotated `/etc/named.conf' at Mon Dec 7 06:34:58 EST 1998.
Reload named now with the new configuration? [Y]
All your basic configuration is now complete. Go ahead and say yes to this so that bind will be restarted.
/etc/resolv.conf is where Linux looks to find out how it should perform DNS lookups. The format is as follows:
domain yourdomain.com
search yourdomain.com otherdomains.com
nameserver 192.168.100.1
nameserver 127.0.0.1
Pretty straight forward. The first line tells it what domain you are in. This can be omitted if you want, but I would recommend using it. The second line is a search pattern. This too can be omitted, but I would also recommend using it. Without it you could not do a lookup of a hostname without typing out it's fully qualified domain name. ie.. you couldn't lookup beavis. You'd have to lookup beavis.otherdomain.com. (Unless you specified this information in your /etc/hosts file)
The "nameserver" lines tell it a search order for DNS servers. Now since we are setting up BIND on your system you will need to change this file. You'll want it to look more like the following:
domain yourdomain.com
search yourdomain.com
nameserver 127.0.0.1
nameserver x.x.x.x
Replace "yourdomain.com" with whatever domain you are using and replace the "x.x.x.x" with a backup DNS server that you can use. (This way if your's fails you still can perform lookups).
Save this file and you should be done. What this gives you so far is the ability to lookup DNS information for the Internet.
Please refer to Setting up a Primary DNS Server, Section 8.4 for information on setting up a working DNS Domain.
named.conf is where you get to tell BIND what where and how. It is the main configuration file for BIND. Prior to BIND 8.x this file was called named.boot. Below is the stock named.conf file you get after installing BIND for the first time.
// generated by named-bootconf.pl
options {
directory "/var/named";
/*
* 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;
};
//
// Boot file for name server
//
// type domain source file
zone "." {
type hint;
file "named.root";
};
// Zone boot information and daemon options are kept in other files
// (autoincluded from boot.zones)
//
// Name server zone boot file
// See named(8) for syntax and further information
//
// type domain source file
// (autoincluded from boot.options)
//
// Options for name server
// Use `bindconfig' to automatically configure this file
//
// type domain source file
zone "localhost" {
type master;
file "named.local";
};
zone "127.in-addr.arpa" {
type master;
file "named.rev-local";
};
// Custom configurations below (will be preserved)
The named.conf file is highly configurable. From just looking at it you can see how to add a new domain. To add a new domain you just add the following at the bottom of your named.conf file:
zone "newdomain.com" {
type master;
file "newdomain.db";
};
zone "100.168.192.in-addr.arpa" {
type master;
file "192.rev";
};
Just replace "newdomain.com" with the name of the domain you are
going to perform DNS for and replace the "100.168.192.in-addr.arpa"
with the proper subnet you will perform reverse DNS for. Note the name of this
reverse lookup zone: it is the numeric IP address of the net in reverse order,
followed by .in-addr.arpa. For more information on how this works
please refer to the BIND documentation located in /usr/share/doc. (if you
installed bind-doc or bind9-doc)
the "type" in the above example specifies whether your will be a master or slave for that domain. type master means your DNS server will not rely on anyone else for information on that domain. Other systems can be setup to perform zone-transfers of that domain. zone-transfers means basically transferring the information to another DNS server so that server can be used to perform DNS lookups. If you are going to pull information from another server you will need to use type slave instead.
The "file" in the above example specifies the actual file name where the information is stored or will be stored. These files will be (or should be) located in /var/named by default. (unless you change the "directory" statement in /etc/named.conf.)
By default BIND is not setup with much security and anyone can pull your information remotely. To control who can perform zone-transfers and thus pull information from your server add this line to your named.conf file:
allow-transfer "192.168.100.1"; /* this line */
This line would go into the options section like so:
options {
directory "/var/named";
allow-transfer "192.168.100.1";
};
Replace the 192.168.100.1 with the IP addresses of those servers you want to be able to perform zone-transfers from your site. NOTE: This does not mean that people not listed here will not be able to perform nslookups from your server. It just means that they have to know what they are looking for. They will have to know a hostname or ip address in order to do a lookup. They will not be able to just pull all the data stored in your database files.
The zone files (or database files) are the heart of your BIND system. This is where all the information is stored on what hostname goes with what ip address.
Here is an example for a domain file for yourdomain.com. Please note this is a very generic example and there are more features to it. Please refer to the BIND documentation for help with these features.
;
; BIND data file for yourdomain.com
;
@ IN SOA yourdomain.com. root.yourdomain.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
IN NS dns.yourdomain.com.
IN MX 10 mail.yourdomain.com.
www IN A 192.168.100.5
dns IN A 192.168.100.10
mail IN A 192.168.100.20
Any line starting with a ; is a comment line and is ignored by BIND. The first 6 lines are configuration lines for the zone. These lines tell it what the zone is (yourdomain.com) who is responsible for it (root.yourdomain.com which is equivalent to [email protected]) and a few other things. These other things include a serial number used for keeping track of when it's updated, how often to refresh the database, how often to retry a zone transfer, when the zone information will expire and a default time to live. *IMPORTANT* Whenever you make changes to the zone file, you MUST increment the serial number. If you do not do this, prolems can occur, especially if you are a primary server supplying information to secondary sites. Most of this information is only used if you have both master and slave systems
The next two lines tell it who the primary DNS server is and who should get the mail for this domain. You can have multiple listings of each of these. To add more dns servers just repeat exactly what is listed changing the dns.yourdomain.com with another dns server. To add another mail server you do the same thing except you have an extra field. The "10" in the MX line states a priority, lower number being first. What this means is if you have 2 MX listings, one is 10 and one is 20, it will try to deliver the mail to the MX listing with the 10 priority and if it fails it will then go to the MX listing with the 20 priority.
The rest of the zone file lists all your hosts and ips. For more information other features and configuration of this information check the BIND documentation.
The reverse lookup files are almost identical to the domain files with only minor changes. Here is an example of a reverse lookup file.
;
; BIND reverse data file for 192.168.100.0
;
@ IN SOA yourdomain.com. root.yourdomain.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
;
IN NS dns.yourdomain.com.
5 IN PTR www.yourdomain.com.
10 IN PTR dns.yourdomain.com.
20 IN PTR mail.yourdomain.com.
The first section of this file is exactly the same as the first section of the domain zone files. The bottom section is where it is different. This time we are listing the last part of the IP address first and then the hostname last.
There are 2 things you must notice here. You have to use the fully qualified domain name here and you must put a "." at the end of it. These 2 things are important to the file and weird things will happen if you don't do it this way. Another possibility is to use "$ORIGIN", which is a domain name that is appended automatically to all names not ending in a dot. The origin can be changed in the db file with $ORIGIN. Do not forget the ending dot from $ORIGIN!
$ORIGIN yourdomain.com.
[Paul Albitz, Cricket Liu: DNS and BIND, O'Reilly & Accosiates, Inc, 1st Edition July 1994, page 136]
The Primary DNS Server is where the master copies of your DNS files are located. It can be either a standalone system or other servers (Secondary) can work off of it by performing zone transfers. A zone transfer is just that, transfering of zone files from one system to another. This is how a Primary server distributes it's zone information to other servers.
This section will cover setting up your Debian system as a Primary DNS server. I'll go through creating a fake domain and configuring BIND to work with that domain.
What we are going to do here is create a new domain. For our purposes we will use foo.org. In this section, we will setup your Debian system to be a Primary server for foo.org.
To give you a better understanding on how all this works, I'll use the following servers with their corresponding IP's for the examples.
www.foo.org = 192.168.100.10
news.foo.org = 192.168.100.20
mail.foo.org = 192.168.100.30
dns.foo.org = 192.168.100.40
dns2.foo.org = 192.168.100.50
Using these for our example, dns.foo.org will represent your Debian server. dns2.foo.org will be used in Setting up a Secondary DNS Server, Section 8.5. You will also see that we are using the 192.168.100.x subnet. For our examples here, we'll be master to this subnet as well.
Now to configure BIND. As shown in Advanced
Configuration, Section 8.3, configuring BIND is rather simple. Again, I'm
not going to cover any advanced configuration, but if you do wish help with it
please check the BIND 8.0 Online
Documentation.
First we need to create 2 files. One for your foo.org domain and one for your
192.168.100.x subnet. We'll start with the foo.org domain file. You need to
create a file called foo.db in /var/named. (This
file cand be called whatever you want but I'm using this for the example). The
file should look somewhat like this:
;
; BIND data file for foo.db
; /var/named/foo.db
;
@ IN SOA foo.org. root.foo.org. (
1998121401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
IN NS dns.foo.org.
IN MX 10 mail.foo.org.
www IN A 192.168.100.10
news IN A 192.168.100.20
mail IN A 192.168.100.30
dns IN A 192.168.100.40
dns2 IN A 192.168.100.50
Notice in the above example that I use 1998121401 as the Serial. I do this for the main reason of keeping track of when the file was last modified. It tells me that the file was last modified 12-14-1998 and it was the first time (01) it was modified that day. You don't have to do this but you do need to make sure you increment the Serial each time you modify it. (Especially if you have Secondaries)
Now you need to create your 192.168.100.x subnet file. So create a file called
192.168.100.db in /var/named. It needs to look
somewhat like this:
;
; BIND reverse data file for 192.168.100.0
; /var/named/192.168.100.db
;
@ IN SOA foo.org. root.foo.org. (
1998121401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
IN NS dns.foo.org.
10 IN PTR www.foo.org.
20 IN PTR news.foo.org.
30 IN PTR mail.foo.org.
40 IN PTR dns.foo.org.
50 IN PTR dns2.foo.org.
Please note the (.) at the end of each hostname (eg. www.foo.org.) The period MUST be there otherwise your zone will not be read correctly by BIND.
Now we need to add your new domain to the BIND configuration file. So go ahead
and edit your /etc/named.conf file and add the following lines at
the bottom.
zone "foo.org" {
type master;
file "foo.db";
};
zone "100.168.192.in-addr.arpa" {
type master;
file "192.168.100.rev";
};
Now save that file and your done. All you have to do now is do a
/etc/init.d/bind reload and test it out. For help with testing
out BIND, please check Testing, Section 8.6.
A Secondary DNS Server is basically just a backup server. I does not hold the master versions of the zone information but rather it holds copies of them. Most sites use Secondary servers in remote locations or to cut down on the load on the Primary server. The Secondary server performs zone transfers at said times making sure it has the newest versions of the zone information.
The big difference in setting up a Primary server and a Secondary server is that your zone files are already built. The only changes you have to make is telling BIND on both systems that this server is a Secondary and to perform zone transfers.
First we need to make changes to your Primary server so that it knows about
your new Secondary server. On your Primary, edit your foo.db
domain file and add the following line to it. (note: complete file is being
shown here)
;
; BIND data file for foo.db
; /var/named/foo.db
;
@ IN SOA foo.org. root.foo.org. (
1998121401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
IN NS dns.foo.org.
IN NS dns2.foo.org. ; ADD THIS LINE ***
IN MX 10 mail.foo.org.
www IN A 192.168.100.10
news IN A 192.168.100.20
mail IN A 192.168.100.30
dns IN A 192.168.100.40
dns2 IN A 192.168.100.50
Now edit your /var/named/192.168.100.db file and do the same.
;
; BIND reverse data file for 192.168.100.0
; /var/named/192.168.100.db
;
@ IN SOA foo.org. root.foo.org. (
1998121401 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Default TTL
IN NS dns.foo.org.
IN NS dns2.foo.org. ; ADD THIS LINE ***
10 IN PTR www.foo.org.
20 IN PTR news.foo.org.
30 IN PTR mail.foo.org.
40 IN PTR dns.foo.org.
50 IN PTR dns2.foo.org.
What your doing by adding the new IN NS line is telling BIND that dns2.foo.org is also a authorized DNS server for both foo.org and the 192.168.100.x subnet. With BIND 8.x this also tells bind that whenever a change is made to the zone files, it needs to notify dns2.foo.org that a change has been made so thaht dns2.foo.org can perform a zone transfer.
Please note that if you have setup your Primary server to only allow zone
transfers from specific hosts, you'll need to make sure that dns2.foo.org is
included in that list. (allows-transfer option in
/etc/named.conf.)
You can now reload your BIND on your Primary server. (/etc/init.d/bind
reload)
Now on your Secondary server you need to add information to your
/etc/named.conf file. Add the following lines to the bottom of
/etc/named.conf:
zone "foo.org" {
type slave;
file "foo.db";
masters {
192.168.100.40;
};
};
zone "100.168.192.in-addr.arpa" {
type slave;
file "192.168.100.db";
masters {
192.168.100.40;
};
};
The above tells BIND that your server is a slave (Secondary) for foo.org and the 192.168.100.x subnet. It also tells BIND that it needs to obtain the zone information (foo.db and 192.168.100.db) from 192.168.100.40 which is dns.foo.org.
Because this is a Secondary Server, there is no need to do anything with zone files. BONUS! As long as you have everything setup right on your Primary and your named.conf file is configured properly, everything will work properly.
You are done. Reload your BIND and test it out. /etc/init.d/bind
reload
Now. Each time the Primary site's zone files are modified and the Serial # is incremented, BIND will send out a notify to all Secondaries (any server in the zone file with a IN NS statement) stating a change has been made. BIND on each of these servers will then check it's own zone files to see if it has the same version or not. If the version that the Primary has notified it about is newer then it will perform a zone transfer and obtain the newer version.
If everything is setup properly, you will never need to make any changes to your Secondary server except to upgrade BIND itself. All changes from here on out should be made on the Primary server. The exception is if a new zone is added on the primary, you need to add it to the secondaries also if you want them to be secondary to the new zone.
Testing is the easy part. If you followed the directions listed here everything should work fine. The first thing you need to do before we can properly test is to reload the database.
/etc/init.d/bind reload
Then you need to go ahead and load up nslookup and run some queries
snowcrash:~# nslookup
Default Server: localhost
Address: 127.0.0.1
>
First off when you run nslookup it should look like the above example unless you have created your own domain and are using an ip address other than 127.0.0.1. You should be able to type in www.debian.org and it should think for a few and return with www.debian.org's ip address.
If you are following the instructions here for setting up a new domain, your nslookup should look more like this:
snowcrash:~# nslookup
Default Server: dns.foo.org
Address: 192.168.100.40
>
You should be able to now lookup each of the hosts we added to your zone files. (www.foo.org, mail.foo.org, etc...)
The following sites are good sources of help for BIND.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ next ]
Debian GNU/Linux Network Administrator's Manual (Obsolete Documentation)
This manual is OBSOLETE and DEPRECATED since 2000, Instead see http://www.debian.org/doc/user-manuals#quick-reference[email protected][email protected][email protected][email protected]