The best reference I've ever found is the official
Bind 9 Reference Manual.
This isn't bad either, though it's scattered around several different pages. Anyway, by way of quick explanation, here's one of mine, sanitized with hostnames and IP addresses changed:
Code: Select all
$TTL 86400;
dummy.org. IN SOA a.dummy.org. hostmaster.dummy.org. (
2005021614;
18000;
3600;
604800;
86400;
)
NS ns.dummy.org.
MX 10 mx.dummy.org.
ns.dummy.org. A 192.168.0.1
b.dummy.org. A 192.168.0.2
c.dummy.org. A 192.168.0.3
d.dummy.org. A 192.168.0.4
a.dummy.org. CNAME ns.dummy.org.
e.dummy.org. A 192.168.0.5
f.dummy.org. A 192.168.0.6
mx.dummy.org. A 192.168.0.7
www.dummy.org. CNAME mx.dummy.org.
g.dummy.org. CNAME mx.dummy.org.
h.dummy.org. CNAME mx2.dummy.org.
mx2.dummy.org. A 192.168.0.8
i.dummy.org. A 192.168.0.9
www2.dummy.org. CNAME j.dummy.org.
j.dummy.org. A 192.168.0.10
k.dummy.org. A 192.168.0.11
Section by section...
Code: Select all
dummy.org. IN SOA a.dummy.org. hostmaster.dummy.org. (
This line should begin with the domain, then the master name server ("source of authority"), then a contact email address (with a '.' instead of '@').
Code: Select all
2005021614;
18000;
3600;
604800;
86400;
The first number here is the serial number; it can be anything you want, but usual practice is to use a timestamp in YYYYMMDDHH format. It should be increased whenever the zone file is edited, so that BIND will reload the updated zone on startup.
The next four are the refresh time (how long slave servers will wait before querying the master about zone updates), the retry time (how long slave servers will wait before retrying a failed query to the master), the expiration time (how long a slave server's replica of the zone remains valid if it can't contact the master), and the negative TTL (how long negative answers to queries, ie a host not found, will be cached). These will rarely vary substantially between different zones.
Code: Select all
NS ns.dummy.org.
MX 10 mx.dummy.org.
The nameservers and mail exchangers for the domain. You can have multiple NS records. You can also have mutlple MX records, each with a different priority; the lowesr priority will be preferred. Note that you can only define NS and MX records with names that are defined later on by A records; you can't use IP addresses or a CNAME.
Everything below is fairly straightforward... an address (A) record is defined by the full hostname (including trailing '.') followed by "A" and the address. A CNAME is an alias that points to an existing A record.
By the way, this is one reason why many people prefer to use alternative DNS servers like djbdns or maradns (another is security; BIND has a poor security record). I used djbdns briefly some time ago, but I don't remember it well enough to say anything about it.