Nutshell Primer on Bind 8i. Contents1. Overview of Bind 8There are two different types of syntax, we are basing all our examples on Bind version 8. (The other is version 4, which we won't discuss.) In a basic layout, we have three sets of files, the /etc/named.conf file, the db.ADDR file and the db.REVERSE file. The main file, /etc/named.conf, is the master file that points to where the other files are, what they are called, and what they contain. The other two files are specific about the hosts in the domain. The db.ADDR file lists all the hosts in the domain, and their IP's. This "forward lookup" file, is used for converting domain names to ips, and holds a list of all the hosts in the domain, no matter how many subnets they span across. On the other hand, the db.REVERSE file, or "reverse look up" file, is specific to each subnet. It contains the IPs and then their host names, but if there are three subnets for a domain, since it is specific to each subnet, there needs to be three separate db.REVERSE files. This file is used when the IP is known, but the hostname is not. 
- /etc/named.conf file: This is the main configuration file for BIND. It is always named: /etc/named.conf which makes it pretty easy to find. This file points to all the other database files and specify what domains it is master to, and who it is a slave to.
- db.ADDR file: This is the standard name lookup file, sometime called a forward lookup table. This table defines names to ip addresses. We use one file for all the different subnets that are under the same domain name grouping (like *.chuck.com).
- db.REVERSE file: This is a collection of files, in this example we have three. There needs to be a separate file for each class "C" subnet, and also a file for the servers loopback address (127.0.0.0)
2. The /etc/named.conf FileThe most improtant file is the /etc/named.conf the /etc/named.conf file |
---|
2a01
2a02 // BIND configuration file
2a03
2a04 options {
2a05 directory "/usr/local/named';
2a06 // Place additional options here.
2a07 };
2a08
2a09 zone "chuck.com" in {
2a10 type master;
2a11 file "db.chuck";
2a12 };
2a13
2a14 zone "1.6.10.in-addr.arpa" in {
2a15 type master;
2a16 file "db.10.6.1";
2a17 };
2a18
2a19 zone "50.6.10.in-addr.arpa" in {
2a20 type master;
2a21 file "db.10.6.50";
2a22 };
2a23
2a24 zone "0.0.127.in-addr.arpa" in {
2a25 type master;
2a26 file "db.127.0.0";
2a27 };
2a28
2a29 zone "." in {
2a30 type hint;
2a31 file "db.cashe";
2a32 };
2a33
2a34 zone "smcint.com" in {
2a35 type slave;
2a36 file "db.smcint";
2a37 masters { 192.168.235.30; };
2a38 };
2a39
2a40 zone "235.168.192.in-addr.arpa" in {
2a41 type slave;
2a42 file "db.192.168.235";
2a43 masters { 192.168.235.30; };
2a44 };
|
For mapping hostnames to addresses. This file would be called: db.chuck the db.ADDR file |
---|
3a01 @ IN SOA NS1.chuck.com. mowgli.mail.chuck.com. (
3a01 1 ; Serial
3a01 10800 ; Refresh after 3 hours
3a01 3600 ; Retry after 1 hour
3a01 604800 ; Expire after 1 week
3a01 86400 ) ; Minimum TTL of 1 day
3a01 ;
3a01 ; Name servers (The name '@' is implied)
3a01 ;
3a01 IN NS NS1.chuck.com
3a01 IN NS NS2.chuck.com
3a01
3a01 ;
3a01 ; Addresses for the canonical names
3a01 ;
3a01 localhost IN A 127.0.0.1
3a01 red IN A 10.6.1.10
3a01 green IN A 10.6.1.11
3a01 brown IN A 10.6.1.12
3a01 blue IN A 10.6.1.13
3a01 purple IN A 10.6.1.14
3a01
3a01 magenta IN A 10.6.50.10
3a01 azure IN A 10.6.50.11
3a01 mahogany IN A 10.6.50.12
3a01 chartreuse IN A 10.6.50.13
3a01
3a01 ;
3a01 ; Aliases
3a01 ;
3a01 quake IN CNAME red
3a01 music IN CNAME brown
3a01 backup IN CNAME azure
|
In our example, "chuck.com" maintains two subnets plus its loopback, which is where we get three files for this example. In this example we have three db.reverse files: This is the contents of the file named db.10.6.1 the db.10.6.1 file |
---|
01 ! --
;
; Origin added to names not ending in
; dot: 1.6.10.in-addr.arpa
;
@ IN SOA NS1.chuck.com. mowgli.mail.chuck.com. (
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
; Name servers (The name '@' is implied)
;
IN NS NS1.chuck.com
IN NS NS2.chuck.com
;
; Addresses point to canonical name
;
10 IN PTR red.chuck.com.
11 IN PTR green.chuck.com.
12 IN PTR brown.chuck.com.
13 IN PTR blue.chuck.com.
14 IN PTR purple.chuck.com.
|
This is the contents of the file named: db.10.6.50 the db.10.6.50 file |
---|
01 ! --
;
; Origin added to names not ending in
; dot: 50.6.10.in-addr.arpa
;
@ IN SOA NS1.chuck.com. mowgli.mail.chuck.com. (
1 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
;
; Name servers (The name '@' is implied)
;
IN NS NS1.chuck.com
IN NS NS2.chuck.com
;
; Addresses point to canonical name
;
10 IN PTR magenta
11 IN PTR azure
12 IN PTR mahogony
13 IN PTR chartreuse
|
The contents of the file db.127.0.0
5. More Advanced Features6. Definitions- SOA Record: Start Of Authority. Indicates authority for this zone. Or, "The SOA record indicates that this name server is the best source of information for the data within this zone. An SOA record is required in each db.DOMAIN and db.ADDR file. There can be one, and only one, SOA record in a db file."1
- IN: The IN stands for internet. This is one class of data. Other classes exist, but none of them are currently in widespread use. The class field is optional, if the class is omitted, the class IN is assumed.
- NS Record: Lists a name server for this zone
- A: Name-to-Address mapping
- PTR: Address-to-Name mapping. This is used in the db.reverse files when specifying a ip to name listing. Addresses should only point to a single name: the canonical name. You can create two PTR record records for a single host, but most systems are not prepared to see more that one name for an address. 3
- CNAME: Canonical name (for aliases). Note: "The name server handles CNAME records in a different manner than aliases are handled in the host table. When a name server looks up a name and finds a CNAME record, it replaces the name with the canonical name and looks up the new name."2
- @: If the domain name is the same as the origin, the name can be specified as "@". This means that instead of having to list the names in the file red.chuck.com., you can instead name it red and the rest is implied. Note that if the name ends with a "." then the shortening will not work.
- type slave: Within a /etc/named.conf file. The type slave specify's what zone it's slave over, and what's the ip of the master server of that domain. There should be both forward and reverse lookups for slave zones (db.addr and db.reverse files).
- Serial SOA value: This applies to all data within a zone. When a slave name server contacts a master server for zone data, it first asks for the serial number on that data. If the slave's serial number is lower than the master server's, the slave zone data are out of date. In this case, the slave pulls a new copy of the of the zone. If you modify the the db files on the primary master, you must increment the serial number or the slave will not upload the changes. A good format for the serial number is YYYYMMDDNN, where NN is a counter for a specific day. (ie: 2000112601) Also note that with bind 8 on both the master and slave servers, the primary master will notify the slave that a zone has been changed within 15 minutes of loading a new copy of that zone.
- Refresh SOA value: The refresh interval tells the slave how often to check that its data are up to date.
- Retry SOA value: If the slave fails to reach the master name server(s) after the refresh period (the hosts could be down), then it starts to trying to connect after every every retry period.
- Expire SOA value: If the slave fails to contact the master server(s) for expire seconds, the slave expires its data. Expiring the data means that the slave stops giving out answers about the data because the data are too old to be useful.
- TTL SOA value: TTL stands for time to live. This value applies to all the resource records in the db file.
- MX Record: specify a mail exchanger for a domain name: a host will either process or forward mail for the domain name. The number following the MX label is the mail exchanger preference value. The preference of a possible mail server is higher if the number is lower. (thus 0 would be considered the highest preference. -you can also have mail sent to two servers with the same preference - they load balance.) For an example, gwu would have a MX listing as such:
gwu.edu. IN MX 0 gwis2.circ.gwu.edu. gwu.edu. IN MX 10 felix.seas.gwu.edu. gwu.edu. IN MX 20 mail.law.gwu.edu.
This would send all mail to "gwu.edu" to gwis2, but if it went down, seas could accept their mail, and if they both went down, then the mail could go to the law school.
|