* bind *
20030207

INTRO:

bind is a DNS (domain name service) server.  DNS is a distributed services
which translates host names to IPs (A records) and IPs to host names (PTR). 
DNS also handles host aliases (CNAME), name server records (NS), and mail
server records (MX).

For more information about DNS, use google, check out some RFCs, and see the
book on DNS by O'Reilly.  For information about bind, man bind, see the
documentation in /usr/share/doc/bind, and also:

http://www.isc.org/products/BIND/
http://www.tldp.org/HOWTO/DNS-HOWTO.html


SETUP:

This document covers BIND 8.
Use Debian to install bind, bind-doc (for documentation), and dnsutils
(probably already installed, contains dig and nslookup; not nslookup is
deprecated, with host suggested for lookups instead).

* named.conf: Configuration files are kept in /etc/bind/.  The main config
file is named.conf.  There are a lot of options here, many of which I don't
fully understand, so I won't cover them here.  man named.conf and see the
howto and /usr/share/doc/ documentation.  named.conf contains options,
logging, and zones.  Here's are two example zones from a primary name
server:

  zone "example.com" {
          type master;
          file "/etc/bind/db.example.com";
  };

  zone "0.168.192.in-addr.arpa" {
          type master;
          file "/etc/bind/db.rev.0";
  };

What this basically does is refer queries about example.com to the file
/etc/bind/db.example.com (which better exist).  

And one from a secondary name server:

  zone "example.com" {
          type slave;
          file "named.example.com";
          masters {
                  129.168.0.1;
          };
  };

* zone files: Note that both forward (name to IP) and reverse (IP to name)
zones are needed.  The format of these files is extremely,
extremely important.  I can't stress this enough.  If it's not exactly as it
should be, BIND will not start and we will not having working DNS.

* header: Taking a look at db.example.com, the first thing is a header,
which is very particular.

  $TTL    86400
  @       IN      SOA     example.com. hostmaster.example.com. (
                  2003020601      ; Serial
                  3600            ; Refresh -- 1 hour
                  1800            ; Retry -- 30 minutes
                  604800          ; Expire -- 1 week
                  86400 )         ; Negative Cache TTL --- 1 hour

  @       IN      NS      ns1.example.com.
  @       IN      NS      ns2.example.com.
  @       IN      MX 1    mail.example.com.

  @       IN      A       192.168.0.2

I've indented the above by two spaces, but otherwise, that's exactly how it
looks, with the '$TTL' part being the very first line in the file.  TTL is
time to live; that is, how long other dns servers should cache this
information more (in seconds).  SOA is start of authority, which contains
the domain and a contact email address (note there's no @ sign in it
though), and then within parenthesis, serial, refresh, retry, expire, and
negative cache TTL.  The semicolon indicates that the rest of the line is a
comment.

Serial is a date stamp, specified  as yyyymmddnn, where nn is the number of
times the file has been updated in one day.  Zones will only be reloaded if
this number is greater than the previous number, so if you do make any
changes, make sure you increment this.  Refresh, retry, expire, and negative
cache TTL all refer, like TTL, to how long this information should be cached
for.

Next up are name server records (NS), a mail server record (MX), and an A
record for our domain which says that 'example.com' (no host specified),
should refer to marathon.example.com.  Note that this isn't actually
needed for mail delivery which relies not on A recoreds but on the MX
record.  Note again that the format is important, including a required
period at the end of the NS and MX lines.

* CNAMEs: Now we move to the records. First we have some aliases or CNAMES. 
It's easier to provide examples than to explain, so (indented two spaces
again):

  web		IN CNAME	llama
  print		IN CNAME	cria
  
* A records: Then there are A records which map host names to IPs.  We have
been including mac addresses as comments, but this is not strictly required. 
Note that the IPs need not be in sequential order; it just makes it easier
to maintain.  Again, examples:

  llama		IN A	192.168.0.3
  cria		IN A	192.168.0.4

* PTR: But the above doesn't give us everything we want.  It will translate
llama to 192.168.0.3, but it wasn't translate 192.168.0.3 back to llama.  For
this we need PTR records.  It is very important to make sure there are
reverse records for every forward record.  Read the previous sentence again,
and remember it.

So looking at db.rev.0, the zone file for reverse DNS for 192.168.0.x, we
see a header at the beginning and then records like the following:

  3      IN      PTR     llama.example.com.
  4      IN      PTR     cria.example.com.

Again, the format matters.  A lot.  There are a few things to note.  Entire
IPs aren't specified as in the A records, just the last octet (the last quad
of the IP, called an octet as 256=2^8).  However, fully qualified host names
are specified (host.example.com rather than just host).  And each line
must end in a period.  Failing to provide one will cause DNS to break when
restarted.

I think that's about it for primary DNS configuration.  If all is set up
correctly, DNS should work.


MAINTENANCE:

bind is stopped and started with '/etc/init.d/bind stop' and
'/etc/init.d/bind start'.  bind logs to /var/log/daemon.log; it's probably
good to 'tail -f' this file while restarting bind.  Also you should check
that the process /usr/sbin/named is running.  And us the 'host' command to
test that DNS is working properly (lookup by both host and by IP).  'dig' is
another very useful tool; see the man page.