Bind 9 DNS
Views:
Contents |
Introduction
This page discusses configuring and operating a Bind 9 DNS server. Examples are taken from a SLES 9 server but really most of it should apply no matter the flavour of nix you are using.
Bind runs chrooted to /var/lib/named, inside that directory you will see a small recreation of the root file system.
Bind Directory Layout
/
|-bin
|-etc
`-var
`-lib
`-named
|-dev
|-dyn
|-etc
| `-named.d
|-log
|-master
|-slave
`-var
|-lib
| `-named -> ../..
|-log -> ../log
`-run
`-named
master
The master directory holds the zone data files for varndean.ac.uk (varndean.ac.uk.zone) and it's accompanying reverse lookup data (80-28.118.219.212.in-addr.arpa.zone). These are text files and can be easily edited using the vi text-editor. The most important things to remember are that you must increment the serial numbers at the top of these files, and also that for every DNS name you add or remove, you must also add/remove the accompanying pointer in the reverse-lookup data file.
etc
The etc directory contains the configuration data for Bind. For example where to store log data and how to find the data records containing the DNS names and IP addresses. Don't edit anything in this folder! It may seem strange but you need to edit configuration data in /etc (the one at the root of the filesystem). The init script for Bind deals with updating /var/lib/named/etc/ automatically. Basically if edit the wrong file your changes will be overwritten the next time Bind is restarted.
With our small set up we should only need to make changes in /etc/named.conf
log & var/log
The log information for bind can be configured in /etc/named.conf, although this file says to store logs in /var/log remember that Bind runs chrooted so the logs are actually in /var/lib/named/var/log
slave
This folder is only used if bind is configured and a secondary/backup name server for any zone. The zone data files will be created by Bind automatically so there's no need to edit anything in this folder. Currently bind is not configured as a backup for any zones.
Zone Data Backup
Zone data is also held on an (possibly off-site or third party) backup DNS server. At Varndean we used one operated by the JISC, ns3.ja.net. With a third party backup server, arrangements will need to be made if the the primary DNS records move to another server, so that the third pary (JISC in our case) can update their server.
At Varndean we also set up a dedicated server (called Enyo) as a backup incase of any serious issues with JANet (that's not likely though!).
Any changes to the zone data need be automatically replicated to ns3.ja.net and Enyo so long as the serial numbers in our datafiles are incremented and the server is reloaded correctly.
We created a rule in Bind's configuration file which allows ns3.ja.net and Enyo to receive updates. This rule would need to be changed if we ever add/change backup servers.
Configuration
The configuration file is /etc/named.conf and the zone data can be found in /var/lib/named/masters/
The configuration file is fairly straigh forward and contains lots of comments. Usually we should only ever need to make changes to the bottom of the file where the config of our zones is written.0
- When ever you make a change to a zone file you must increment it's serial number
- After any changes (to named.conf or a zone file), you must run the rndc command as the super-user.
Syntax
named.conf
Fairly straight forward, but key points for info:
- comment lines start with # (there are others but this will do)
- options typically start with a keyword followed by a name and then a value
- options end in a semicolon
- multiple sub-values/sub-options are wrapped in brackets { }
Access Control
Access control lists are defined in the config file and can be used to do things such as making the server use a different configuration when dealing with college computers and non-college computers on the internet.
At Varndean we used ACLs to control the sending of updates to our backup servers, blocking invalid (spoof) ip addresses and allowing recursion for queries originating in the DMZ and LAN.
For Example:
acl "janetDNS" { ns3.ja.net; };
This simply creates an ACL called 'janetDNS' which we can refer to in other config options. The janetDNS rule refers to a host called ns3.ja.net but we could have just as easily used an ip address or listed multiple hosts.
zone data files
Zone data files are be thought of as having two halves: the top of the file contains what's known as the Start of Authority; the bottom half contains the resource records of all the names and numbers for the zone.
DNS names can be written in one of two ways:
- FQDNs (Fully Qualified Domain Names) are written with an extra dot at the end. Eg: ares.varndean.ac.uk.
- Relative domain names are written only as the host name, with out any information on the domain and without a trailing dot. The name of the zone is automatically appended to the host name. Eg: ares
Start of Authority
This part of the zone data is unlikely to change very often, and great care should be taken when it does need to change. A small error can knock out the entire zone.
Example:
80/28.118.219.212.in-addr.arpa. IN SOA 80/28.118.219.212.in-addr.arpa. support.varndean.ac.uk. (
2005122214 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d ) ; minimum
- The first part of this is the 'origin', basically the domain name of the zone in question.
- IN means the class of the record is 'Internet' (all are records will be like this)
- SOA mean Start of Authority
- again the origin
- the next part is an email address - one that is actually checked regularly!! (no excuses!!). It looks strange because there is no @ sign. For some reason the @ sign is used as short hand for the origin. The first dot in the email address is changed to the @ sign (that makes an email like some.body@example.com impossible to use in this situation, you must always use an address that doesn't contain a dot in the username like somebody@example.com)
- The remaining items are surrounded by brackets so watch out!
- The serial number must go up each time the zone data is updated.
- The serial number is, by mandatory convention, written as the date in ISO format, followed by two digits starting at 01. Always keep the date part time with the date of the change and start the remaining two digits back at 01 for the first edit of the day.
- The other values tell resolvers how long to cache results they get from our server.
Other Resource Records
There are three main types of records for a 'names to numbers' zone (eg varndean.ac.uk):
- A = address
- CNAME = alais
- MX = mail exchange
A brief example:
metis IN A 212.219.118.84 mail IN CNAME metis varndean.ac.uk. IN MX 5 mail.varndean.ac.uk. student.varndean.ac.uk. IN MX 5 mail.varndean.ac.uk.
Some people out there on the net preach that you should not use CNAMEs but instead use multiple A records all pointing to the same ip. The idea is that CNAMEs put too great a load on the server but frankly thats complete rubbish (a, dns lookups are cheap. b, everything gets cached by servers all over the net). Please don't use multiple A records for the same ip address, use an A record for the actual host name and CNAME records for any aliases.
Options
options {
directory "/var/lib/named";
dump-file "/var/log/named/dump.db";
statistics-file "/var/log/named/stats";
listen-on-v6 { none; };
query-source address * port 53;
transfer-source * port 53;
notify-source * port 53;
notify yes;
interface-interval 0;
max-transfer-time-in 60;
allow-recursion { varndean; };
allow-query { varndean; };
blackhole { bogon; };
};
varndean.ac.uk
This is the 'names to numbers' zone. It's the one that stores all our dns names the ip addresses or alias name they match up to. There is a small amount of basic configuration data in /etc/named.conf:
zone "varndean.ac.uk" in {
type master;
file "master/varndean.ac.uk.zone";
allow-transfer { janetDNS; };
allow-query { any; }
};
This just specifies the zone in question, that we are the 'Master' (primary) server, where the zone data file is and who to allow transfers to.
Here's an example of our 'names to numbers' zone:
@ IN SOA ares.varndean.ac.uk. support.varndean.ac.uk. (
2005122226 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d) ; minimum
IN NS ares.varndean.ac.uk.
IN NS ns3.ja.net.
ares.varndean.ac.uk. IN A 212.219.118.91
metis.varndean.ac.uk. IN A 212.219.118.84
hydra.varndean.ac.uk. IN A 212.219.118.94
online.varndean.ac.uk. IN CNAME ares.varndean.ac.uk.
mail.varndean.ac.uk. IN CNAME metis.varndean.ac.uk.
80/28.118.219.212.in-addr.arpa
This is the 'numbers to names' zone. It stores a list of node address from our network (ie. the last octet of the ip address) and the name they match up to. Note: don't take account of aliases in this zone. Just point to the canonical name of the server.
The relevant part of the bind configuration file for this zone is:
zone "80/28.118.219.212.in-addr.arpa" in {
type master;
file "master/80-28.118.219.212.in-addr.arpa.zone";
allow-transfer { janetDNS; };
allow-query { any; };
};
Here is an example of the zone data for our 'numbers to names' zone:
80/28.118.219.212.in-addr.arpa. IN SOA 80/28.118.219.212.in-addr.arpa. support.varndean.ac.uk. (
2005122214 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1d ) ; minimum
80/28.118.219.212.in-addr.arpa. IN NS ares.varndean.ac.uk.
80/28.118.219.212.in-addr.arpa. IN NS ns3.ja.net.
84 IN PTR metis.varndean.ac.uk.
91 IN PTR ares.varndean.ac.uk.
94 IN PTR hydra.varndean.ac.uk.
rndc
rndc is a tool used to monitor and configure Bind. It must be run as the root user.
Each time you make a change to a config file or zon edata file you must use rndc to make Bind re-read the files:
# rndc reload #
To get a status report for Bind, use rndc with the status option:
# rndc status number of zones: 6 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is ON server is up and running #
