<!doctype linuxdoc system>
<!-- -*-SGML-*- -->
<article>
<title>DNS HOWTO <author>Nicolai Langfeldt (<tt/dns-howto(at)langfeldt.net/),
Jamie Norrish and others 
<date>v9.0, 2001-12-20
<abstract>
HOWTO become a totally small time DNS admin.
</abstract>

<toc>

<sect>Preamble

<p>Keywords: DNS, BIND, BIND 4, BIND 8, BIND 9, named, dialup, PPP,
slip, ISDN, Internet, domain, name, resolution, hosts, caching.

<p>This document is part of the Linux Documentation Project.

<sect1>Legal stuff

<p>(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish &amp; Co. Do
not modify without amending copyright, distribute freely but retain
copyright message.

<sect1>Credits and request for help.

<p>I want to thank all the people that I have bothered with reading
this HOWTO (you know who you are) and all the readers that have
e-mailed suggestions and notes.

<p>This will never be a finished document; please send me mail about
your problems and successes.  You can help make this a better HOWTO.
So please send comments and/or questions or money to
janl(at)langfeldt.net.  Or buy my DNS book (it's titled "The Concise
Guide to DNS and BIND, the bibliography has ISBNs).  If you send
e-mail and want an answer please show the simple courtesy of
<em/making sure/ that the return address is correct and working.
Also, <bf/please/ read the <ref id="qanda" name="qanda"> section
before mailing me.  Another thing, I can only understand Norwegian and
English.

<p>This is a HOWTO.  I have maintained it as part of the LDP since
1995.  I have, during 2000, written a book on the same subject.  I
want to say that, though this HOWTO is in many ways much like the book
it is <em>not</em> a watered down version concocted to market the
book.  The readers of this HOWTO have helped me understand what is
difficult to understand about DNS.  This has helped the book, but the
book has also helped me to think more about what this HOWTO needs.
The HOWTO begot the book.  The book begot version 3 of this HOWTO.  My
thanks to the book publisher, Que, that took a chance on me :-)

<!-- This is a comment meant for translators:

If you're a translator you may put information about reaching someone
speaking the language you translate to, and that can help with DNS
problems, such as yourself, here (otherwise I get mail in chinese and
spanish asking for help about DNS)

If you want to translate this HOWTO please notify me so I can keep
track of what languages it has been published in, and also I can
notify you when the HOWTO has been updated. 

Please also do not replace "(at)" in my e-mail address above with and
"@", but do translate it if needed. I hope to reduce the amount of
spam I get in this way, or at least not increase it.

-->

<sect1>Dedication

<p>This HOWTO is dedicated to Anne Line Norheim Langfeldt.  Though she
will probably never read it since she's not that kind of girl.

<sect1>Updated versions

<p>You should be able to find updated versions of this HOWTO both at
<url url="http://langfeldt.net/DNS-HOWTO/"> and on <url
url="http://www.linuxdoc.org/">.  Go there if this document is dated
more than 9 months ago.

<sect>Introduction.<label id="intro">

<p><bf/What this is and isn't./

<p>DNS is the Domain Name System.  DNS converts machine names to the
IP addresses that all machines on the net have.  It translates (or
"maps" as the jargon would have it) from name to address and from
address to name, and some other things.  This HOWTO documents how to
define such mappings using Unix system, with a few things specific to
Linux.

<p>A mapping is simply an association between two things, in this case
a machine name, like <tt/ftp.linux.org/, and the machine's IP number
(or address) <tt/199.249.150.4/.  DNS also contains mappings the other
way, from the IP number to the machine name; this is called a "reverse
mapping".

<p>DNS is, to the uninitiated (you ;-), one of the more opaque areas
of network administration.  Fortunately DNS isn't really that hard.
This HOWTO will try to make a few things clearer.  It describes how to
set up a <em/simple/ DNS name server, starting with a caching only
server and going on to setting up a primary DNS server for a domain.
For more complex setups you can check the <ref id="qanda"
name="qanda"> section of this document.  If it's not described there
you will need to <em/read/ the Real Documentation.  I'll get back to
what this Real Documentation consists of in <ref id="bigger" name="the
last chapter">.

<p>Before you start on this you should configure your machine so that
you can telnet in and out of it, and successfully make all kinds of
connections to the net, and you should especially be able to do
<tt/telnet 127.0.0.1/ and get your own machine (test it now!).  You
also need good <tt>/etc/nsswitch.conf</tt>, <tt>/etc/resolv.conf</tt>
and <tt>/etc/hosts</tt> files as a starting point, since I will not
explain their function here.  If you don't already have all this set
up and working the Networking-HOWTO and/or the
Networking-Overview-HOWTO explains how to set it up.  Read them.

<p>When I say `your machine' I mean the machine you are trying to set
up DNS on, not any other machine you might have that's involved in
your networking effort.

<p>I assume you're not behind any kind of firewall that blocks name
queries.  If you are you will need a special configuration --- see the
section on <ref id="qanda" name="qanda">.

<p>Name serving on Unix is done by a program called <tt/named/.  This
is a part of the ``BIND'' package which is coordinated by <em/The
Internet Software Consortium/.  <tt/Named/ is included in most Linux
distributions and is usually installed as <tt>/usr/sbin/named</tt>,
usually from a package called <tt/BIND/, in upper or lower case
depending on the whim of the packager.

<p>If you have a named you can probably use it; if you don't have one
you can get a binary off a Linux ftp site, or get the latest and
greatest source from <url url="ftp://ftp.isc.org/isc/bind9/">.  This
HOWTO is about BIND version 9.  The old versions of the HOWTO, about
BIND 4 and 8, is still available at <url
url="http://langfeldt.net/DNS-HOWTO/"> in case you use BIND 4 or 8
(incidentally, you will find this HOWTO there too).  If the named man
page talks about (at the very end, in the FILES section)
<tt/named.conf/ you have BIND 8; if it talks about <tt/named.boot/ you
have BIND 4.  If you have 4 and are security conscious you really
ought to upgrade to the latest version of BIND 8.  Now.

<p>DNS is a net-wide database.  Take care about what you put into it.
If you put junk into it, you, and others, will get junk out of it.
Keep your DNS tidy and consistent and you will get good service from
it.  Learn to use it, admin it, debug it and you will be another good
admin keeping the net from falling to its knees by mismanagement.

<p><bf/Tip:/ Make backup copies of all the files I instruct you to
change if you already have them, so that if after going through this
nothing works you can get it back to your old, working state.

<sect1>Other nameserver implementations.

<p>This section was written by Joost van Baal.

<p>Various packages exist for getting a DNS server on your box.  There
is the BIND package (<url url="http://www.isc.org/products/BIND/">);
the implementation this HOWTO is about.  It's the most popular
nameserver around and it's used on the vast majority of name serving
machines on the Internet, around and being deployed since the 1980's.
It's available under a BSD license.  Since it's the most popular
package, loads of documentation and knowledge about BIND is around.
However, there have been security problems with BIND.

<p>Then there is djbdns (<url url="http://djbdns.org/">), a relatively
new DNS package written by Daniel J. Bernstein, who also wrote qmail.
It's a very modular suite: various small programs take care of the
different jobs a nameserver is supposed to handle.  It's designed with
security in mind.  It uses a simpler zone-file format, and is
generally easier to configure.  However, since it's less well known,
your local guru might not be able to help you with this.
Unfortunately, this software is not Open Source.  The author's
advertisement is on <url url="http://cr.yp.to/djbdns/ad.html">.

<p>Whether DJBs software is really an improvement over the older
alternatives is a subject of much debate.  A discussion (or is it a
flame-war?) of BIND vs djbdns, joined by ISC people, is on <url
url="http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html">

<sect>A resolving, caching name server.<label id="caching">

<p><bf/A first stab at DNS config, very useful for dialup, cable-modem, 
ADSL and similar users./

<p>On Red Hat and Red Hat related distributions you can achieve the
same practical result as this HOWTO's first section by installing the
packages <tt/bind/, <tt/bind-utils/ and <tt/caching-nameserver/.  If
you use Debian simply install <tt/bind/ (or <tt/bind9/, as of this
writing, BIND 9 is not supported by Debian Stable (potato)) and
<tt/bind-doc/.  Of course just installing those packages won't teach
you as much as reading this HOWTO.  So install the packages, and then
read along verifying the files they installed.

<p>A caching only name server will find the answer to name queries and
remember the answer the next time you need it.  This will shorten the
waiting time the next time significantly, especially if you're on a
slow connection.

<p>First you need a file called <tt>/etc/named.conf</tt> (Debian:
<tt>/etc/bind/named.conf</tt>).  This is read when named starts.  For
now it should simply contain:

<code>
// Config file for caching only name server
//
// The version of the HOWTO you read may contain leading spaces
// (spaces in front of the characters on these lines ) in this and
// other files.  You must remove them for things to work.
//
// Note that the filenames and directory names may differ, the
// ultimate contents of should be quite similar though.

options {
	directory "/var/named";

	// Uncommenting this might help if you have to go through a
	// firewall and things are not working out.  But you probably
	// need to talk to your firewall admin.

	// query-source port 53;
};

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

key "rndc_key" {
        algorithm hmac-md5;
        secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};

zone "." {
        type hint;
        file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
        type master;
        file "pz/127.0.0";
};
</code>

<p>The Linux distribution packages may use different file names for
each kind of file mentioned here; they will still contain about the
same things.

<p>The `<tt/directory/' line tells named where to look for files.  All
files named subsequently will be relative to this.  Thus <tt>pz</tt>
is a directory under <tt>/var/named</tt>, i.e.,
<tt>/var/named/pz</tt>.  <tt>/var/named</tt> is the right directory
according to the <em/Linux File system Standard/.

<p>The file named <tt>/var/named/root.hints</tt> is named in this.
<tt>/var/named/root.hints</tt> should contain this:
<code>
;
; There might be opening comments here if you already have this file.
; If not don't worry.
;
; About any leading spaces in front of the lines here: remove them!
; Lines should start in a ;, . or character, not blanks.
;
.                       6D  IN      NS      A.ROOT-SERVERS.NET.
.                       6D  IN      NS      B.ROOT-SERVERS.NET.
.                       6D  IN      NS      C.ROOT-SERVERS.NET.
.                       6D  IN      NS      D.ROOT-SERVERS.NET.
.                       6D  IN      NS      E.ROOT-SERVERS.NET.
.                       6D  IN      NS      F.ROOT-SERVERS.NET.
.                       6D  IN      NS      G.ROOT-SERVERS.NET.
.                       6D  IN      NS      H.ROOT-SERVERS.NET.
.                       6D  IN      NS      I.ROOT-SERVERS.NET.
.                       6D  IN      NS      J.ROOT-SERVERS.NET.
.                       6D  IN      NS      K.ROOT-SERVERS.NET.
.                       6D  IN      NS      L.ROOT-SERVERS.NET.
.                       6D  IN      NS      M.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.     6D  IN      A       198.41.0.4
B.ROOT-SERVERS.NET.     6D  IN      A       128.9.0.107
C.ROOT-SERVERS.NET.     6D  IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     6D  IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     6D  IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     6D  IN      A       192.5.5.241
G.ROOT-SERVERS.NET.     6D  IN      A       192.112.36.4
H.ROOT-SERVERS.NET.     6D  IN      A       128.63.2.53
I.ROOT-SERVERS.NET.     6D  IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     6D  IN      A       198.41.0.10
K.ROOT-SERVERS.NET.     6D  IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     6D  IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     6D  IN      A       202.12.27.33
</code>

<p>The file describes the root name servers in the world.  The servers
change over time and must be maintained now and then.  See the <ref
id="maint" name="maintenance section"> for how to keep it up to date.

<p>The next section in <tt/named.conf/ is the last <tt/zone/.  I will
explain its use in a later chapter; for now just make this a file
named <tt/127.0.0/ in the subdirectory <tt/pz/: (<em/Again, please
remove leading spaces if you cut and paste this/)

<code>
$TTL 3D
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
				1       ; Serial
				8H	; Refresh
				2H      ; Retry
				4W	; Expire
				1D)	; Minimum TTL
			NS      ns.linux.bogus.
1			PTR	localhost.
</code>

<p>The sections called <tt/key/ and <tt/controls/ together specify
that your named can be remotely controlled by a program called
<tt/rndc/ if it connects from the local host, and identifis itself
with the encoded secret key.  This key is like a password.  For rndc
to work you need <tt>/etc/rndc.conf</tt> to match this:

<code>
key rndc_key {
    algorithm "hmac-md5";
    secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};

options {
    default-server localhost;
    default-key    rndc_key;
};
</code>

<p>As you see the secret is identical.  If you want to use <tt/rndc/
from other machines their times need to be within 5 minutes of
eachother.  I recommend using the ntp (<tt/xntpd/ and <tt/ntpdate/)
software to do this.

<p>Next, you need a <tt>/etc/resolv.conf</tt> looking something like
this: (<em/Again: Remove spaces!/)

<code>
search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1
</code>

<p>The `<tt/search/' line specifies what domains should be searched
for any host names you want to connect to.  The `<tt/nameserver/' line
specifies the address of your nameserver, in this case your own
machine since that is where your named runs (127.0.0.1 is right, no
matter if your machine has another address too).  If you want to list
several name servers put in one `<tt/nameserver/' line for
each. (Note: Named never reads this file, the resolver that uses named
does. Note 2: In some resolv.conf files you find a line saying
"domain".  That's fine, but don't use both "search" and "domain", only
one of them will work).

<p>To illustrate what this file does: If a client tries to look up
<tt>foo</tt>, then <tt>foo.subdomain.your-domain.edu</tt> is tried
first, then <tt>foo.your-domain.edu</tt>, and finally <tt>foo</tt>.
You may not want to put in too many domains in the search line, as it
takes time to search them all.

<p>The example assumes you belong in the domain
<tt>subdomain.your-domain.edu</tt>; your machine, then, is probably
called <tt>your-machine.subdomain.your-domain.edu</tt>.  The search
line should not contain your TLD (Top Level Domain, `<tt/edu/' in this
case).  If you frequently need to connect to hosts in another domain
you can add that domain to the search line like this: (<em/Remember to
remove the leading spaces, if any/)

<code>
search subdomain.your-domain.edu your-domain.edu other-domain.com
</code>

and so on. Obviously you need to put real domain names in instead.
Please note the lack of periods at the end of the domain names.  This
is important; please note the lack of periods at the end of the domain
names.

<sect1>Starting named<label id="starting">

<p>After all this it's time to start named.  If you're using a dialup
connection connect first.  Now run named, either by running the boot
script: <tt>/etc/init.d/named start</tt> or named directly:
<tt>/usr/sbin/named</tt>.  If you have tried previous versions of BIND
you're probably used to <tt/ndc/.  I BIND 9 it has been replaced with
<tt/rndc/, which can controll your named remotely, but it can't start
named anymore. If you view your syslog message file (usually called
<tt>/var/log/messages</tt>, Debian calls it <tt>/var/log/daemon</tt>,
another directory to look is the other files <tt>/var/log</tt>) while
starting named (do <tt>tail -f /var/log/messages</tt>) you should see
something like:

<p>(the lines ending in \ continues on the next line)

<tscreen><verb>
Dec 23 02:21:12 lookfar named[11031]: starting BIND 9.1.3
Dec 23 02:21:12 lookfar named[11031]: using 1 CPU
Dec 23 02:21:12 lookfar named[11034]: loading configuration from \
    '/etc/named.conf'
Dec 23 02:21:12 lookfar named[11034]: the default for the \
    'auth-nxdomain' option is now 'no'
Dec 23 02:21:12 lookfar named[11034]: no IPv6 interfaces found
Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface lo, \
    127.0.0.1#53
Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface eth0, \
    10.0.0.129#53
Dec 23 02:21:12 lookfar named[11034]: command channel listening on \
    127.0.0.1#953
Dec 23 02:21:13 lookfar named[11034]: running
</verb></tscreen>

<p>If there are any messages about errors then there is a mistake.
Named will name the file it is reading.  Go back and check the file.
Start named over when it is fixed.

<p>Now you can test your setup.  Traditionally a program called
<tt/nslookup/ is used for this.  These days <tt/dig/ is recommended:

<tscreen><verb>
$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26669
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200  IN      PTR     localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.   259200  IN      NS      ns.linux.bogus.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 02:26:17 2001
;; MSG SIZE  rcvd: 91
</verb></tscreen>

<p>If that's what you get it's working.  We hope.  Anything very
different, go back and check everything.  Each time you change a
file you need to run <tt/rndc reload/.

<p>Now you can enter a query.  Try looking up some machine close to
you.  <tt/pat.uio.no/ is close to me, at the University of Oslo:

<tscreen><verb>
$ dig pat.uio.no
; <<>> DiG 9.1.3 <<>> pat.uio.no
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15574
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;pat.uio.no.                    IN      A

;; ANSWER SECTION:
pat.uio.no.             86400   IN      A       129.240.130.16

;; AUTHORITY SECTION:
uio.no.                 86400   IN      NS      nissen.uio.no.
uio.no.                 86400   IN      NS      nn.uninett.no.
uio.no.                 86400   IN      NS      ifi.uio.no.

;; Query time: 651 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 02:28:35 2001
;; MSG SIZE  rcvd: 108
</verb></tscreen>

<p>This time <tt/dig/ asked your named to look for the machine
<tt/pat.uio.no/.  It then contacted one of the name server machines
named in your <tt/root.hints/ file, and asked its way from there.  It
might take tiny while before you get the result as it may need to
search all the domains you named in <tt>/etc/resolv.conf</tt>.  

<!-- Hum, this version of dig does not seem to show the aa flag.  Odd.
And nslookup always says "non-authoritative".  A change in behaviour
here, need to check if that is permanent or not.

Please note the "aa" on the "flags:" line.  It means that the answer
is authoritative, that it is fresh from an authoritative server.  I'll
explain "authoritative" later. -->

<p>If you ask the same again you get this:

<tscreen><verb>
$ dig pat.uio.no

; <<>> DiG 8.2 <<>> pat.uio.no 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;;      pat.uio.no, type = A, class = IN

;; ANSWER SECTION:
pat.uio.no.             23h59m58s IN A  129.240.130.16

;; AUTHORITY SECTION:
UIO.NO.                 23h59m58s IN NS  nissen.UIO.NO.
UIO.NO.                 23h59m58s IN NS  ifi.UIO.NO.
UIO.NO.                 23h59m58s IN NS  nn.uninett.NO.

;; ADDITIONAL SECTION:
nissen.UIO.NO.          23h59m58s IN A  129.240.2.3
ifi.UIO.NO.             1d23h59m58s IN A  129.240.64.2
nn.uninett.NO.          1d23h59m58s IN A  158.38.0.181

;; Total query time: 4 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:23:09 2000
;; MSG SIZE  sent: 28  rcvd: 162
</verb></tscreen>

<!-- 
<p>Note the lack of a "aa" flag in this answer. That means that named
did not go out on the network to ask this time, as the information is
in the cache now.  But the cached information <em/might/ be out of
date (stale).  So you are informed of this (very slight) possibility
by the "aa" not being there.  But, now you know that your cache is
working. -->

<p>As you can plainly see this time it was much faster, 4ms versus
more than half a second earlier.  The answer was cached.  With cached
answers there is the possibility that the answer is out of date, but
the origin servers can control the time cached answers should be
considered valid, so there is a high probability that the answer you
get <em/is/ valid.

<sect1>Resolvers

<p>All OSes implementing the standard C API has the calls
gethostbyname and gethostbyaddr.  These can get information from
several different sources.  Which sources it gets it from is
configured in <tt>/etc/nsswitch.conf</tt> on Linux (and some other
Unixes).  This is a long file specifying from which file or database
to get different kinds of data types.  It usually contains helpful
comments at the top, which you should consider reading.  After that
find the line starting with `<tt/hosts:/'; it should read:

<code>
hosts:      files dns
</code>

(<em/You remembered about the leading spaces, right? I won't mention
them again./)

<p>If there is no line starting with `<tt/hosts:/' then put in the one
above.  It says that programs should first look in the
<tt>/etc/hosts</tt> file, then check DNS according to
<tt/resolv.conf/.


<sect1>Congratulations

<p>Now you know how to set up a caching named.  Take a beer, milk, or
whatever you prefer to celebrate it.


<sect>Forwarding

<p>In large, well organized, academic or ISP (Internet Service
Provider) networks you will sometimes find that the network people
have set up a forwarder hierarchy of DNS servers which helps lighten
the internal network load and the load on the outside servers as well.
It's not easy to know if you're inside such a network or not.  But by
using the DNS server of your network provider as a ``forwarder'' you
can make the responses to queries faster and less of a load on your
network.  This works by your nameserver forwarding queries to your ISP
nameserver.  Each time this happens you will dip into the big cache of
your ISPs nameserver, thus speeding your queries up, your nameserver
does not have to do all the work itself.  If you use a modem this can
be quite a win.  For the sake of this example we assume that your
network provider has two name servers they want you to use, with IP
numbers <tt/10.0.0.1/ and <tt/10.1.0.1/.  Then, in your
<tt/named.conf/ file, inside the opening section called
``<tt/options/'', insert these lines:

<code>
           forward first;
           forwarders {
                10.0.0.1;
                10.1.0.1;
            };
</code>

<p>There is also a nice trick for dialup machines using forwarders, it
is described in the <ref id="qanda" name="qanda"> section.

<p>Restart your nameserver and test it with <tt/dig/.  Should still
work fine.

<sect>A <em/simple/ domain.<label id="simple">

<p><bf>How to set up your own domain.</bf>

<sect1>But first some dry theory

<p>First of all: you read all the stuff before here right? You have
to.

<p>Before we <em/really/ start this section I'm going to serve you
some theory on and an example of how DNS works.  And you're going to
read it because it's good for you.  If you don't want to you should at
least skim it very quickly.  Stop skimming when you get to what should
go in your <tt/named.conf/ file.

<p>DNS is a hierarchical, tree structured system.  The top is written
`<tt/./' and pronounced `root', as is usual for tree data-structures.
Under <tt/./ there are a number of Top Level Domains (TLDs); the best
known ones are <tt/ORG/, <tt/COM/, <tt/EDU/ and <tt/NET/, but there
are many more.  Just like a tree it has a root and it branches out.
If you have any computer science background you will recognize DNS as
a search tree, and you will be able to find nodes, leaf nodes and
edges.  The dots are nodes, the edges are on the names.

<p>When looking for a machine the query proceeds recursively into the
hierarchy starting at the root.  If you want to find the address of
<tt/prep.ai.mit.edu./, your nameserver has to start asking somewhere.
It starts by looking it its cache.  If it knows the answer, having
cached it before, it will answer right away as we saw in the last
section.  If it does not know it will see how closely it can match the
requested name and use whatever information it has cached.  In the
worst case there is no match but the `.' (root) of the name, and the
root servers have to be consulted.  It will remove the leftmost parts
one at a time, checking if it knows anything about <tt/ai.mit.edu./,
then <tt/mit.edu./, then <tt/edu./, and if not that it does know about
<tt/./ because that was in the hints file.  It will then ask a <tt/./
server about <tt/prep.ai.mit.edu/. This <tt/./ server will not know
the answer, but it will help your server on its way by giving a
referral, telling it where to look instead.  These referrals will
eventually lead your server to a nameserver that knows the answer.  I
will illustrate that now.  <tt/+norec/ means that dig is asking
non-recursive questions so that we get to do the recursion ourselves.
The other options are to reduce the amount of dig produces so this
won't go on for too many pages:

<tscreen><verb>
$ ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; AUTHORITY SECTION:
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
.                       518400  IN      NS      L.ROOT-SERVERS.NET.
.                       518400  IN      NS      M.ROOT-SERVERS.NET.
.                       518400  IN      NS      A.ROOT-SERVERS.NET.
.                       518400  IN      NS      B.ROOT-SERVERS.NET.
.                       518400  IN      NS      C.ROOT-SERVERS.NET.
.                       518400  IN      NS      D.ROOT-SERVERS.NET.
.                       518400  IN      NS      E.ROOT-SERVERS.NET.
.                       518400  IN      NS      F.ROOT-SERVERS.NET.
.                       518400  IN      NS      G.ROOT-SERVERS.NET.
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
</verb></tscreen>

<p>This is a referral. It is giving us an "Authority section" only, no
"Answer section". Our own nameserver refers us to a nameserver.  Pick
one at random:

<tscreen><verb>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; AUTHORITY SECTION:
mit.edu.                172800  IN      NS      BITSY.mit.edu.
mit.edu.                172800  IN      NS      STRAWB.mit.edu.
mit.edu.                172800  IN      NS      W20NS.mit.edu.

;; ADDITIONAL SECTION:
BITSY.mit.edu.          172800  IN      A       18.72.0.3
STRAWB.mit.edu.         172800  IN      A       18.71.0.151
W20NS.mit.edu.          172800  IN      A       18.70.0.160
</verb></tscreen>

<p>It refers us to MIT.EDU servers at once.  Again pick one at random:

<tscreen><verb>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; ANSWER SECTION:
prep.ai.mit.edu.        10562   IN      A       198.186.203.77

;; AUTHORITY SECTION:
ai.mit.edu.             21600   IN      NS      FEDEX.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      LIFE.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      ALPHA-BITS.ai.mit.edu.
ai.mit.edu.             21600   IN      NS      BEET-CHEX.ai.mit.edu.

;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu.       21600   IN      A       192.148.252.43
LIFE.ai.mit.edu.        21600   IN      A       128.52.32.80
ALPHA-BITS.ai.mit.edu.  21600   IN      A       128.52.32.5
BEET-CHEX.ai.mit.edu.   21600   IN      A       128.52.32.22
</verb></tscreen>

<p>This time we got a "ANSWER SECTION", and an answer for our
question.  The "AUTHORITY SECTION" contains information about which
servers to ask about <tt/ai.mit.edu/ the next time.  So you can ask
them directly the next time you wonder about <tt/ai.mit.edu/ names.
Named also gathered information about <tt/mit.edu/, so of
<tt/www.mit.edu/ is requested it is much closer to being able to
answer the question.

<p>So starting at <tt/./ we found the successive name servers for each
level in the domain name by referral.  If you had used your own DNS
server instead of using all those other servers, your named would
of-course cache all the information it found while digging this out
for you, and it would not have to ask again for a while.

<p>In the tree analogue each ``<tt/./'' in the name is a branching
point.  And each part between the ``<tt/./''s are the names of
individual branches in the tree.  One climbs the tree by taking the
name we want (<tt/prep.ai.mit.edu/) asking the root (<tt/./) or
whatever servers father from the root toward <tt/prep.ai.mit.edu/ we
have information about in the cache.  Once the cache limits are
reached the recursive resolver goes out asking servers, pursuing
referrals (edges) further into the name.

<p>A much less talked about, but just as important domain is
<tt/in-addr.arpa/.  It too is nested like the `normal' domains.
<tt/in-addr.arpa/ allows us to get the host's name when we have its
address.  A important thing to note here is that the IP addresses are
written in reverse order in the <tt/in-addr.arpa/ domain.  If you have
the address of a machine: <tt/198.186.203.77/ named proceeds to find
the named 77.203.168.198.in-addr.arpa/ just like it did for
<tt/prep.ai.mit.edu/.  Example: Finding no cache entry for any match
but `.', ask a root server, <tt/m.root-servers.net/ refers you to some
other root servers.  <tt/b.root-servers.net/ refers you directly to
<tt//bitsy.mit.edu/.  You should be able to take it from there.


<sect1>Our own domain

<p>Now to define our own domain.  We're going to make the domain
<tt/linux.bogus/ and define machines in it.  I use a totally bogus
domain name to make sure we disturb no-one Out There.

<p>One more thing before we start: Not all characters are allowed in
host names.  We're restricted to the characters of the English
alphabet: a-z, and numbers 0-9 and the character '-' (dash).  Keep to
those characters (BIND 9 will not bug you if you break this rule, BIND
8 will). Upper and lower-case characters are the same for DNS, so
<tt/pat.uio.no/ is identical to <tt/Pat.UiO.No/.

<p>We've already started this part with this line in <tt/named.conf/:

<code>
zone "0.0.127.in-addr.arpa" {
	type master;
	file "pz/127.0.0";
};
</code>

<p>Please note the lack of `<tt/./' at the end of the domain names in
this file.  This says that now we will define the zone
<tt/0.0.127.in-addr.arpa/, that we're the master server for it and
that it is stored in a file called <tt>pz/127.0.0</tt>.  We've already
set up this file, it reads:

<code>
$TTL 3D
@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (
				1       ; Serial
				8H	; Refresh
				2H      ; Retry
				4W	; Expire
				1D)	; Minimum TTL
			NS      ns.linux.bogus.
1			PTR	localhost.
</code>

<p>Please note the `<tt/./' at the end of all the full domain names in
this file, in contrast to the <tt/named.conf/ file above. Some people
like to start each zone file with a <tt/&dollar;ORIGIN/ directive, but
this is superfluous.  The origin (where in the DNS hierarchy it
belongs) of a zone file is specified in the zone section of the
<tt/named.conf/ file; in this case it's <tt/0.0.127.in-addr.arpa/.

<p>This `zone file' contains 3 `resource records' (RRs): A SOA RR.  A
NS RR and a PTR RR.  SOA is short for Start Of Authority.  The `@' is a
special notation meaning the origin, and since the `domain' column for
this file says 0.0.127.in-addr.arpa the first line really means

<tscreen><verb>
0.0.127.in-addr.arpa.	IN	SOA ...
</verb></tscreen>

<p>NS is the Name Server RR.  There is no '@' at the start of this
line; it is implicit since the previous line started with a '@'.
Saves some typing that.  So the NS line could also be written

<tscreen><verb>
0.0.127.in-addr.arpa.	IN	NS	ns.linux.bogus
</verb></tscreen>

<p>It tells DNS what machine is the name server of the domain
<tt/0.0.127.in-addr.arpa/, it is <tt/ns.linux.bogus/.  'ns' is a
customary name for name-servers, but as with web servers who are
customarily named <tt/www./<em/something/. The name may be anything.

<p>And finally the PTR (Domain Name Pointer) record says that the host
at address 1 in the subnet <tt/0.0.127.in-addr.arpa/, i.e., 127.0.0.1
is named <tt/localhost/.

<p>The SOA record is the preamble to <em/all/ zone files, and there
should be exactly one in each zone file, at the top (but after the
<tt/$TTL/ directive).  It describes the zone, where it comes from (a
machine called <tt/ns.linux.bogus/), who is responsible for its
contents (<tt/hostmaster@linux.bogus/; you should insert your e-mail
address here), what version of the zone file this is (serial: 1), and
other things having to do with caching and secondary DNS servers.  For
the rest of the fields (refresh, retry, expire and minimum) use the
numbers used in this HOWTO and you should be safe.  Before the SOA
comes a mandatory line, the <tt/$TTL 3D/ line.  Put it in all your
zone files.

<p>Now restart your named (<tt/rndc stop; named/) and use <tt/dig/ to
examine your handy work.  <tt/-x/ asks for the inverse query:

<tscreen><verb>
$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200  IN      PTR     localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.   259200  IN      NS      ns.linux.bogus.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:02:39 2001
;; MSG SIZE  rcvd: 91
</verb></tscreen>

<p>So it manages to get <tt/localhost/ from 127.0.0.1, good.  Now for
our main task, the <tt/linux.bogus/ domain, insert a new 'zone'
section in <tt/named.conf/:

<code>
zone "linux.bogus" {
	type master;
	notify no;
	file "pz/linux.bogus";
};
</code>

<p>Note again the lack of ending `<tt/./' on the domain name in the
<tt/named.conf/ file.

<p>In the <tt/linux.bogus/ zone file we'll put some totally bogus
data:

<code>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds
;
		NS	ns		; Inet Address of name server
		MX	10 mail.linux.bogus	; Primary Mail Exchanger
		MX	20 mail.friend.bogus.	; Secondary Mail Exchanger
;
localhost	A	127.0.0.1
ns		A	192.168.196.2
mail		A	192.168.196.4
</code>

<p>Two things must be noted about the SOA record.  <tt/ns.linux.bogus/
<em/must/ be a actual machine with a A record.  It is not legal to
have a CNAME record for the machine mentioned in the SOA record.  Its
name need not be `ns', it could be any legal host name.  Next,
<tt/hostmaster.linux.bogus/ should be read as hostmaster@linux.bogus.
This should be a mail alias, or a mailbox, where the person(s)
maintaining DNS should read mail frequently.  Any mail regarding the
domain will be sent to the address listed here.  The name need not be
`hostmaster', it can be your normal e-mail address, but the e-mail
address `hostmaster' is often expected to work as well.

<p>There is one new RR type in this file, the MX, or Mail eXchanger
RR.  It tells mail systems where to send mail that is addressed to
<tt/someone@linux.bogus/, namely to <tt/mail.linux.bogus/ or
<tt/mail.friend.bogus/.  The number before each machine name is that
MX RR's priority.  The RR with the lowest number (10) is the one mail
should be sent to if possible.  If that fails the mail can be sent to
one with a higher number, a secondary mail handler, i.e.,
<tt/mail.friend.bogus/ which has priority 20 here.

<p>Reload named by running <tt/rndc reload/.  Examine the results
with <tt/dig/:

<tscreen><verb>
$ dig any linux.bogus
; <<>> DiG 9.1.3 <<>> any linux.bogus
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;linux.bogus.               IN      ANY

;; ANSWER SECTION:
linux.bogus.        259200  IN      SOA     ns.linux.bogus. \
      hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus.        259200  IN      NS      ns.linux.bogus.
linux.bogus.        259200  IN      MX      20 mail.friend.bogus.
linux.bogus.        259200  IN      MX      10 mail.linux.bogus.linux.bogus.

;; AUTHORITY SECTION:
linux.bogus.        259200  IN      NS      ns.linux.bogus.

;; ADDITIONAL SECTION:
ns.linux.bogus.     259200  IN      A       192.168.196.2

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:06:45 2001
;; MSG SIZE  rcvd: 184
</verb></tscreen>

<p>Upon careful examination you will discover a bug.  The line

<tscreen><verb>
linux.bogus.        259200  IN MX        10 mail.linux.bogus.linux.bogus.
</verb></tscreen>

<p>is all wrong.  It should be

<tscreen><verb>
linux.bogus.        259200  IN MX        10 mail.linux.bogus.
</verb></tscreen>

<p>I deliberately made a mistake so you could learn from it :-)
Looking in the zone file we find this line:

<tscreen><verb>
		MX	10 mail.linux.bogus	; Primary Mail Exchanger
</verb></tscreen>

<p>It is missing a period.  Or has a 'linux.bogus' too many.  If a
machine name does not end in a period in a zone file the origin is
added to its end causing the double <tt/linux.bogus.linux.bogus/.  So
either

<code>
		MX	10 mail.linux.bogus.	; Primary Mail Exchanger
</code>

or

<code>
		MX	10 mail			; Primary Mail Exchanger
</code>

is correct.  I prefer the latter form, it's less to type.  There are
some BIND experts that disagree, and some that agree with this.  In a
zone file the domain should either be written out and ended with a
`<tt/./' or it should not be included at all, in which case it
defaults to the origin.

<p>I must stress that in the named.conf file there should <em/not/ be
`<tt/./'s after the domain names.  You have no idea how many times a
`<tt/./' too many or few have fouled up things and confused the h*ll
out of people.

<p>So having made my point here is the new zone file, with some extra
information in it as well:

<code>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds
;
		TXT	"Linux.Bogus, your DNS consultants"
		NS	ns		; Inet Address of name server
		NS	ns.friend.bogus.
		MX	10 mail		; Primary Mail Exchanger
		MX	20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost	A	127.0.0.1

gw		A	192.168.196.1
		TXT	"The router"

ns		A	192.168.196.2
		MX	10 mail
		MX	20 mail.friend.bogus.
www		CNAME	ns

donald		A	192.168.196.3
		MX	10 mail
		MX	20 mail.friend.bogus.
		TXT	"DEK"

mail		A	192.168.196.4
		MX	10 mail
		MX	20 mail.friend.bogus.

ftp		A	192.168.196.5
		MX	10 mail
		MX	20 mail.friend.bogus.
</code>


<p>CNAME (Canonical NAME) is a way to give each machine several names.
So www is an alias for ns.  CNAME record usage is a bit
controversial. But it's safe to follow the rule that a MX, CNAME or
SOA record should <em/never/ refer to a CNAME record, they should only
refer to something with an A record, so it is inadvisable to have

<code>
foobar		CNAME	www			; NO!
</code>

but correct to have

<code>
foobar		CNAME	ns			; Yes!
</code>

<p>Load the new database by running <tt/rndc reload/, which causes
named to read its files again.

<tscreen><verb>
$ dig linux.bogus axfr

; <<>> DiG 9.1.3 <<>> linux.bogus axfr
;; global options:  printcmd
linux.bogus.            259200  IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus.            259200  IN      NS      ns.linux.bogus.
linux.bogus.            259200  IN      MX      10 mail.linux.bogus.
linux.bogus.            259200  IN      MX      20 mail.friend.bogus.
donald.linux.bogus.     259200  IN      A       192.168.196.3
donald.linux.bogus.     259200  IN      MX      10 mail.linux.bogus.
donald.linux.bogus.     259200  IN      MX      20 mail.friend.bogus.
donald.linux.bogus.     259200  IN      TXT     "DEK"
ftp.linux.bogus.        259200  IN      A       192.168.196.5
ftp.linux.bogus.        259200  IN      MX      10 mail.linux.bogus.
ftp.linux.bogus.        259200  IN      MX      20 mail.friend.bogus.
gw.linux.bogus.         259200  IN      A       192.168.196.1
gw.linux.bogus.         259200  IN      TXT     "The router"
localhost.linux.bogus.  259200  IN      A       127.0.0.1
mail.linux.bogus.       259200  IN      A       192.168.196.4
mail.linux.bogus.       259200  IN      MX      10 mail.linux.bogus.
mail.linux.bogus.       259200  IN      MX      20 mail.friend.bogus.
ns.linux.bogus.         259200  IN      MX      10 mail.linux.bogus.
ns.linux.bogus.         259200  IN      MX      20 mail.friend.bogus.
ns.linux.bogus.         259200  IN      A       192.168.196.2
www.linux.bogus.        259200  IN      CNAME   ns.linux.bogus.
linux.bogus.            259200  IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:12:31 2001
;; XFR size: 23 records
</verb></tscreen>

<p>That's good.  As you see it looks a bit like the zone file itself.
Let's check what it says for <tt/www/ alone:

<tscreen><verb>
$ dig www.linux.bogus

; <<>> DiG 9.1.3 <<>> www.linux.bogus
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.linux.bogus.               IN      A

;; ANSWER SECTION:
www.linux.bogus.        259200  IN      CNAME   ns.linux.bogus.
ns.linux.bogus.         259200  IN      A       192.168.196.2

;; AUTHORITY SECTION:
linux.bogus.            259200  IN      NS      ns.linux.bogus.

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:14:14 2001
;; MSG SIZE  rcvd: 80
</verb></tscreen>

<p>In other words, the real name of <tt/www.linux.bogus/ is
<tt/ns.linux.bogus/, and it gives you some of the information it has
about ns as well, enough to connect to it if you were a program.

<p>Now we're halfway.

<sect1>The reverse zone

<p>Now programs can convert the names in linux.bogus to addresses
which they can connect to. But also required is a reverse zone, one
making DNS able to convert from an address to a name. This name is
used by a lot of servers of different kinds (FTP, IRC, WWW and others)
to decide if they want to talk to you or not, and if so, maybe even
how much priority you should be given. For full access to all services
on the Internet a reverse zone is required.

<p>Put this in <tt/named.conf/:

<code>
zone "196.168.192.in-addr.arpa" {
        type master;
	notify no;
        file "pz/192.168.196";
};
</code>

<p>This is exactly as with the <tt/0.0.127.in-addr.arpa/, and the
contents are similar:

<code>
$TTL 3D
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151 ; Serial, todays date + todays serial
			8H	; Refresh
			2H      ; Retry
			4W	; Expire
			1D)	; Minimum TTL
		NS      ns.linux.bogus.

1		PTR	gw.linux.bogus.
2		PTR	ns.linux.bogus.
3		PTR	donald.linux.bogus.
4		PTR	mail.linux.bogus.
5		PTR	ftp.linux.bogus.
</code>

<p>Now you reload your named (<tt/rndc reload/) and examine your
work with <tt/dig/ again:

<code>
$ dig -x 192.168.196.4
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;4.196.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 259200 IN   PTR     mail.linux.bogus.

;; AUTHORITY SECTION:
196.168.192.in-addr.arpa. 259200 IN     NS      ns.linux.bogus.

;; ADDITIONAL SECTION:
ns.linux.bogus.         259200  IN      A       192.168.196.2

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:05 2001
;; MSG SIZE  rcvd: 107
</code>

<p>so, it looks OK, dump the whole thing to examine that too:

<code>
$ dig 196.168.192.in-addr.arpa. AXFR

; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
;; global options:  printcmd
196.168.192.in-addr.arpa. 259200 IN     SOA     ns.linux.bogus. \
	hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN     NS      ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN   PTR     gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN   PTR     ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN   PTR     donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN   PTR     mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN   PTR     ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN     SOA     ns.linux.bogus. \
	hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records
</code>

<p>Looks good!  If your output didn't look like that look for
error-messages in your syslog, I explained how to do that in the first
section under the heading <ref id="starting" name="Starting named">

<sect1>Words of caution

<p>There are some things I should add here.  The IP numbers used in
the examples above are taken from one of the blocks of 'private nets',
i.e., they are not allowed to be used publicly on the Internet.  So
they are safe to use in an example in a HOWTO.  The second thing is
the <tt/notify no;/ line.  It tells named not to notify its secondary
(slave) servers when it has gotten a update to one of its zone files.
In BIND 8 and later the named can notify the other servers listed in
NS records in the zone file when a zone is updated.  This is handy for
ordinary use.  But for private experiments with zones this feature
should be off --- we don't want the experiment to pollute the Internet
do we?

<p>And, of course, this domain is highly bogus, and so are all the
addresses in it.  For a real example of a real-life domain see the
next main-section.

<sect1>Why reverse lookups don't work.

<p>There are a couple of ``gotchas'' that normally are avoided with
name lookups that are often seen when setting up reverse zones.
Before you go on you need reverse lookups of your machines working on
your own nameserver.  If it isn't go back and fix it before
continuing.

<p>I will discuss two failures of reverse lookups as seen from outside
your network:

<sect2>The reverse zone isn't delegated.

<p>When you ask a service provider for a network-address range and a
domain name the domain name is normally delegated as a matter of course.
A delegation is the glue NS record that helps you get from one
nameserver to another as explained in the dry theory section above.
You read that, right?  If your reverse zone doesn't work go back and
read it.  Now.

<p>The reverse zone also needs to be delegated.  If you got the
<tt/192.168.196/ net with the <tt/linux.bogus/ domain from your
provider they need to put <tt/NS/ records in for your reverse zone as
well as for your forward zone.  If you follow the chain from
<tt/in-addr.arpa/ and up to your net you will probably find a break in
the chain, most probably at your service provider.  Having found the
break in the chain contact your service-provider and ask them to
correct the error.

<sect2>You've got a classless subnet

<p>This is a somewhat advanced topic, but classless subnets are very
common these days and you probably have one if you're a small company.

<p>A classless subnet is what keeps the Internet going these days.
Some years ago there was much ado about the shortage of IP numbers.
The smart people in IETF (the Internet Engineering Task Force, they
keep the Internet working) stuck their heads together and solved the
problem.  At a price.  The price is in part that you'll get less than
a ``C'' subnet and some things may break.  Please see <url name="Ask
Mr. DNS" url="http://www.acmebw.com/askmrdns/00007.htm"> for an
good explanation of this and how to handle it.

<p>Did you read it?  I'm not going to explain it so please read it.

<p>The first part of the problem is that your ISP must understand the
technique described by Mr. DNS.  Not all small ISPs have a working
understanding of this.  If so you might have to explain to them and be
persistent.  But be sure you understand it first ;-).  They will then
set up a nice reverse zone at their server which you can examine for
correctness with dig.

<p>The second and last part of the problem is that you must understand
the technique.  If you're unsure go back and read about it again.
Then you can set up your own classless reverse zone as described by
Mr. DNS.

<p>There is another trap lurking here.  (Very) Old resolvers will
<em/not/ be able to follow the <tt/CNAME/ trick in the resolving chain
and will fail to reverse-resolve your machine.  This can result in the
service assigning it an incorrect access class, deny access or
something along those lines.  If you stumble into such a service the
only solution (that I know of) is for your ISP to insert your PTR
record directly into their trick classless zone file instead of the
trick CNAME record.

<p>Some ISPs will offer other ways to handle this, like Web based
forms for you to input your reverse-mappings in or other automagical
systems.

<sect1>Slave servers

<p>Once you have set up your zones correctly on the master servers you
need to set up at least one slave server.  Slave servers are needed
for robustness.  If your master goes down the people out there on the
net will still be able to get information about your domain from the
slave.  A slave should be as long away from you as possible.  Your
master and slave should share as few as possible of these: Power
supply, LAN, ISP, city and country.  If all of these things are
different for your master and slave you've found a really good slave.

<p>A slave is simply a nameserver that copies zone files from a
master.  You set it up like this:

<code>
zone "linux.bogus" {
	type slave;
	file "sz/linux.bogus";
	masters { 192.168.196.2; };
};
</code>

<p>A mechanism called zone-transfer is used to copy the data.  The
zone transfer is controlled by your SOA record:

<code>
@	IN	SOA	ns.linux.bogus. hostmaster.linux.bogus. (
			199802151	; serial, todays date + todays serial #
			8H		; refresh, seconds
			2H		; retry, seconds
			4W		; expire, seconds
			1D )		; minimum, seconds
</code>

<p>A zone is only transferred if the serial number on the master is
larger than on the slave.  Every refresh interval the slave will check
if the master has been updated.  If the check fails (because the
master is unavailable) it will retry the check every retry interval.
If it continues to fail as long as the expire interval the slave will
remove the zone from it's filesystem and no longer be a server for it.


<sect>Basic security options.
<label id="security">

<p><em/By Jamie Norrish/

<p><bf/Setting configuration options to reduce the possibility of
problems./

<p>There are a few simple steps that you can take which will both make
your server more secure and potentially reduce its load. The material
presented here is nothing more than a starting point; if you are
concerned about security (and you should be), please consult other
resources on the net (see <ref id="bigger" name="the last chapter">).

<p>The following configuration directives occur in <tt/named.conf/. If
a directive occurs in the <tt/options/ section of the file, it applies
to all zones listed in that file. If it occurs within a <tt/zone/
entry, it applies only to that zone. A <tt/zone/ entry overrides an
<tt/options/ entry.

<Sect1>Restricting zone transfers

<p>In order for your slave server(s) to be able to answer queries
about your domain, they must be able to transfer the zone information
from your primary server.  Very few others have a need to do so.
Therefore restrict zone transfers using the <tt/allow-transfer/
option, assuming 192.168.1.4 is the IP address of ns.friend.bogus and
adding yourself for debugging purposes:

<code>
zone "linux.bogus" {
      allow-transfer { 192.168.1.4; localhost; };
};
</code>

<p>By restricting zone transfers you ensure that the only information
available to people is that which they ask for directly - no one can
just ask for all the details about your set-up.

<Sect1>Protecting against spoofing

<p>Firstly, disable any queries for domains you don't own, except
from your internal/local machines. This not only helps prevent
malicious use of your DNS server, but also reduces unnecessary use of
your server.

<code>
options {
      allow-query { 192.168.196.0/24; localhost; };
};

zone "linux.bogus" {
      allow-query { any; };
};

zone "196.168.192.in-addr.arpa" {
      allow-query { any; };
};
</code>

<p>Further, disable recursive queries except from internal/local
sources. This reduces the risk of cache poisoning attacks (where false
data is fed to your server).

<code>
options {
	allow-recursion { 192.168.196.0/24; localhost; };
};
</code>

<Sect1>Running named as non-root

<p>It is a good idea to run named as a user other than root, so that
if it is compromised the privileges gained by the cracker are as
limited as possible. You first have to create a user for named to run
under, and then modify whatever init script you use that starts
named. Pass the new user name and group to named using the -u and -g
flags.

<p>For example, in Debian GNU/Linux 2.2 you might modify your
<tt>/etc/init.d/bind</tt> script to have the following line (where
user <tt/named/ have been created):

<code>
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named 
</code>

<p>The same can be done with Red Hat and the other distributions.

<p>Dave Lugo has described a secure dual chroot setup <url
url="http://www.etherboy.com/dns/chrootdns.html"> which you may find
interesting to read, it makes the host your run your named on even
more secure.

<sect>A real domain example<label id="real-example">

<p><bf/Where we list some <em/real/ zone files/

<p>Users have suggested that I include a real example of a working
domain as well as the tutorial example.

<p>I use this example with permission from David Bullock of LAND-5.
These files were current 24th of September 1996, and were then edited
to fit BIND 8 restrictions and use extensions by me.  So, what you see
here differs a bit from what you find if you query LAND-5's name
servers now.

<sect1>/etc/named.conf (or /var/named/named.conf)

<p>Here we find master zone sections for the two reverse zones needed:
the 127.0.0 net, as well as LAND-5's <tt/206.6.177/ subnet, and a
primary line for land-5's forward zone <tt/land-5.com/. Also note that
instead of stuffing the files in a directory called <tt/pz/, as I do
in this HOWTO, he puts them in a directory called <tt/zone/.

<code>
// Boot file for LAND-5 name server

options {
	directory "/var/named";
};

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

key "rndc_key" {
        algorithm hmac-md5;
        secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};

zone "." {
	type hint;
	file "root.hints";
};

zone "0.0.127.in-addr.arpa" {
	type master;
	file "zone/127.0.0";
};

zone "land-5.com" {
	type master;
	file "zone/land-5.com";
};

zone "177.6.206.in-addr.arpa" {
	type master;
	file "zone/206.6.177";
};
</code>

<p>If you put this in your named.conf file to play with <bf/PLEASE/
put ``<tt/notify no;/'' in the zone sections for the two <tt/land-5/
zones so as to avoid accidents.

<sect1>/var/named/root.hints

<p>Keep in mind that this file is dynamic, and the one listed here is
old.  You're better off using a new one as explained earlier.

<code>
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. 
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;;	., type = NS, class = IN

;; ANSWER SECTION:
.			6D IN NS	G.ROOT-SERVERS.NET.
.			6D IN NS	J.ROOT-SERVERS.NET.
.			6D IN NS	K.ROOT-SERVERS.NET.
.			6D IN NS	L.ROOT-SERVERS.NET.
.			6D IN NS	M.ROOT-SERVERS.NET.
.			6D IN NS	A.ROOT-SERVERS.NET.
.			6D IN NS	H.ROOT-SERVERS.NET.
.			6D IN NS	B.ROOT-SERVERS.NET.
.			6D IN NS	C.ROOT-SERVERS.NET.
.			6D IN NS	D.ROOT-SERVERS.NET.
.			6D IN NS	E.ROOT-SERVERS.NET.
.			6D IN NS	I.ROOT-SERVERS.NET.
.			6D IN NS	F.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET.	5w6d16h IN A	192.112.36.4
J.ROOT-SERVERS.NET.	5w6d16h IN A	198.41.0.10
K.ROOT-SERVERS.NET.	5w6d16h IN A	193.0.14.129
L.ROOT-SERVERS.NET.	5w6d16h IN A	198.32.64.12
M.ROOT-SERVERS.NET.	5w6d16h IN A	202.12.27.33
A.ROOT-SERVERS.NET.	5w6d16h IN A	198.41.0.4
H.ROOT-SERVERS.NET.	5w6d16h IN A	128.63.2.53
B.ROOT-SERVERS.NET.	5w6d16h IN A	128.9.0.107
C.ROOT-SERVERS.NET.	5w6d16h IN A	192.33.4.12
D.ROOT-SERVERS.NET.	5w6d16h IN A	128.8.10.90
E.ROOT-SERVERS.NET.	5w6d16h IN A	192.203.230.10
I.ROOT-SERVERS.NET.	5w6d16h IN A	192.36.148.17
F.ROOT-SERVERS.NET.	5w6d16h IN A	192.5.5.241

;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET.  198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE  sent: 17  rcvd: 436
</code>

<sect1>/var/named/zone/127.0.0

<p>Just the basics, the obligatory SOA record, and a record that maps
127.0.0.1 to <tt/localhost/.  Both are required.  No more should be in
this file.  It will probably never need to be updated, unless your
nameserver or hostmaster address changes.

<code>
$TTL 3D
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609203       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
        
1                       PTR     localhost.
</code>

<p>If you look at a random BIND installation you will probably find
that the <tt/$TTL/ line is missing as it is here.  It was not used
before, and only version 8.2 of BIND has started to warn about its
absence.  BIND 9 <em/requires/ the <tt/$TTL/.  

<sect1>/var/named/zone/land-5.com

<p>Here we see the mandatory SOA record, the needed NS records.  We
can see that he has a secondary name server at <tt/ns2.psi.net/.  This
is as it should be, <em/always/ have a off site secondary server as
backup.  We can also see that he has a master host called <tt/land-5/
which takes care of many of the different Internet services, and that
he's done it with CNAMEs (a alternative is using A records).

<p>As you see from the SOA record, the zone file originates at
<tt/land-5.com/, the contact person is
<tt/root@land-5.com/. <tt/hostmaster/ is another oft used address for
the contact person.  The serial number is in the customary yyyymmdd
format with todays serial number appended; this is probably the sixth
version of zone file on the 20th of September 1996.  Remember that the
serial number <em/must/ increase monotonically, here there is only
<em/one/ digit for todays serial&num;, so after 9 edits he has to wait
until tomorrow before he can edit the file again.  Consider using two
digits.

<code>
$TTL 3D
@       IN      SOA     land-5.com. root.land-5.com. (
                        199609206       ; serial, todays date + todays serial #
                        8H		; refresh, seconds
                        2H		; retry, seconds
                        4W		; expire, seconds
                        1D )		; minimum, seconds
                NS      land-5.com.
                NS      ns2.psi.net.
                MX      10 land-5.com.  ; Primary Mail Exchanger
                TXT     "LAND-5 Corporation"

localhost	A	127.0.0.1

router          A       206.6.177.1
        
land-5.com.     A       206.6.177.2
ns		A	206.6.177.3
www             A	207.159.141.192

ftp             CNAME   land-5.com.
mail            CNAME   land-5.com.
news            CNAME   land-5.com.

funn            A       206.6.177.2

;
;       Workstations
;
ws-177200	A       206.6.177.200
                MX      10 land-5.com.   ; Primary Mail Host
ws-177201       A       206.6.177.201
                MX      10 land-5.com.   ; Primary Mail Host
ws-177202       A       206.6.177.202
                MX      10 land-5.com.   ; Primary Mail Host
ws-177203       A       206.6.177.203
                MX      10 land-5.com.   ; Primary Mail Host
ws-177204       A       206.6.177.204
                MX      10 land-5.com.   ; Primary Mail Host
ws-177205       A       206.6.177.205
                MX      10 land-5.com.   ; Primary Mail Host
; {Many repetitive definitions deleted - SNIP}
ws-177250       A       206.6.177.250
                MX      10 land-5.com.   ; Primary Mail Host
ws-177251       A       206.6.177.251
                MX      10 land-5.com.   ; Primary Mail Host
ws-177252       A       206.6.177.252
                MX      10 land-5.com.   ; Primary Mail Host
ws-177253       A       206.6.177.253
                MX      10 land-5.com.   ; Primary Mail Host
ws-177254       A       206.6.177.254
                MX      10 land-5.com.   ; Primary Mail Host
</code>

<p>If you examine land-5s nameserver you will find that the host names
are of the form <tt/ws_/<em/number/.  As of late BIND 4 versions named
started enforcing the restrictions on what characters may be used in
host names.  So that does not work with BIND 8 at all, and I
substituted '-' (dash) for '_' (underline) for use in this HOWTO.
But, as mentioned earlier, BIND 9 no longer enforces this restriction.

<p>Another thing to note is that the workstations don't have
individual names, but rather a prefix followed by the two last parts
of the IP numbers.  Using such a convention can simplify maintenance
significantly, but can be a bit impersonal, and, in fact, be a source
of irritation among your customers.

<p>We also see that <tt/funn.land-5.com/ is an alias for
<tt/land-5.com/, but using an A record, not a CNAME record.

<sect1>/var/named/zone/206.6.177

<p>I'll comment on this file below

<code>
$TTL 3D
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609206       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
                        NS      ns2.psi.net.
;
;       Servers
;
1       PTR     router.land-5.com.
2       PTR     land-5.com.
2       PTR     funn.land-5.com.
;
;       Workstations
;
200     PTR     ws-177200.land-5.com.
201     PTR     ws-177201.land-5.com.
202     PTR     ws-177202.land-5.com.
203     PTR     ws-177203.land-5.com.
204     PTR     ws-177204.land-5.com.
205     PTR     ws-177205.land-5.com.
; {Many repetitive definitions deleted - SNIP}
250     PTR     ws-177250.land-5.com.
251     PTR     ws-177251.land-5.com.
252     PTR     ws-177252.land-5.com.
253     PTR     ws-177253.land-5.com.
254     PTR     ws-177254.land-5.com.
</code>

<p>The reverse zone is the bit of the setup that seems to cause the
most grief.  It is used to find the host name if you have the IP
number of a machine.  Example: you are an FTP server and accept
connections from FTP clients.  As you are a Norwegian FTP server you
want to accept more connections from clients in Norway and other
Scandinavian countries and less from the rest of the world.  When you
get a connection from a client the C library is able to tell you the
IP number of the connecting machine because the IP number of the
client is contained in all the packets that are passed over the
network.  Now you can call a function called gethostbyaddr that looks
up the name of a host given the IP number.  Gethostbyaddr will ask a
DNS server, which will then traverse the DNS looking for the machine.
Supposing the client connection is from ws-177200.land-5.com.  The IP
number the C library provides to the FTP server is 206.6.177.200.  To
find out the name of that machine we need to find
<tt/200.177.6.206.in-addr.arpa/.  The DNS server will first find the
<tt/arpa./ servers, then find <tt/in-addr.arpa./ servers, following
the reverse trail through 206, then 6 and at last finding the server
for the <tt/177.6.206.in-addr.arpa/ zone at LAND-5.  From which it
will finally get the answer that for <tt/200.177.6.206.in-addr.arpa/
we have a ``<tt/PTR ws-177200.land-5.com/'' record, meaning that the
name that goes with <tt/206.6.177.200/ is <tt/ws-177200.land-5.com/.

<p>The FTP server prioritizes connections from the Scandinavian
countries, i.e., <tt/*.no/, <tt/*.se/, <tt/*.dk/, the name
<tt/ws-177200.land-5.com/ clearly does not match any of those, and the
server will put the connection in a connection class with less
bandwidth and fewer clients allowed.  If there was <em/no/ reverse
mapping of <tt/206.2.177.200/ through the <tt/in-addr.arpa/ zone the
server would have been unable to find the name at all and would have
to settle to comparing <tt/206.2.177.200/ with <tt/*.no/, <tt/*.se/
and <tt/*.dk/, none of which will match at all, it may even deny the
connection for lack of classification.

<p>Some people will tell you that reverse lookup mappings are only
important for servers, or not important at all.  Not so: Many ftp,
news, IRC and even some http (WWW) servers will <em/not/ accept
connections from machines of which they are not able to find the name.
So reverse mappings for machines are in fact <em/mandatory/.

<sect>Maintenance<label id="maint">

<p><bf/Keeping it working./

<p>There is one maintenance task you have to do on nameds, other than
keeping them running.  That's keeping the <tt/root.hints/ file
updated.  The easiest way is using <tt/dig/. First run <tt/dig/ with
no arguments you will get the <tt/root.hints/ according to your own
server.  Then ask one of the listed root servers with <tt/dig
@rootserver/.  You will note that the output looks terribly like a
<tt/root.hints/ file.  Save it to a file (<tt/dig @e.root-servers.net
. ns &gt;root.hints.new/) and replace the old <tt/root.hints/ with it.

<p>Remember to reload named after replacing the cache file.

<p>Al Longyear sent me this script that can be run automatically to
update <tt/root.hints/.  Install a crontab entry to run it once a
month and forget it.  The script assumes you have mail working and
that the mail-alias `hostmaster' is defined.  You must hack it to suit
your setup.

<code>
#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for BIND 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
# named up-test suggested by Erik Bryer.
#
(
 echo "To: hostmaster <hostmaster>"
 echo "From: system <root>"

 # Is named up? Check the status of named.
 case `rndc status 2>&1` in
    *refused*)
        echo "named is DOWN. root.hints was NOT updated"
        echo
        exit 0
        ;;
 esac

 PATH=/sbin:/usr/sbin:/bin:/usr/bin:
 export PATH
 # NOTE: /var/named must be writable only by trusted users or this script 
 # will cause root compromise/denial of service opportunities.
 cd /var/named 2>/dev/null || {
    echo "Subject: Cannot cd to /var/named, error $?"
    echo
    echo "The subject says it all"
    exit 1
 }

 # Are we online?  Ping a server at your ISP
 case `ping -qnc 1 some.machine.net 2>&1` in
   *'100% packet loss'*)
        echo "Subject: root.hints NOT updated.  The network is DOWN."
	echo
	echo "The subject says it all"
	exit 1
	;;
 esac

 dig @e.root-servers.net . ns >root.hints.new 2> errors

 case `cat root.hints.new` in
   *NOERROR*)
	# It worked
	:;;
   *)
	echo "Subject: The root.hints file update has FAILED."
        echo
   	echo "The root.hints update has failed"
	echo "This is the dig output reported:"
   	echo
   	cat root.hints.new errors
        exit 1
	;;
 esac

 echo "Subject: The root.hints file has been updated"
 echo
 echo "The root.hints file has been updated to contain the following   
information:"
 echo
 cat root.hints.new

 chown root.root root.hints.new
 chmod 444 root.hints.new
 rm -f root.hints.old errors
 mv root.hints root.hints.old
 mv root.hints.new root.hints
 rndc restart
 echo
 echo "The nameserver has been restarted to ensure that the update is complete."
 echo "The previous root.hints file is now called   
/var/named/root.hints.old."
) 2>&1 | /usr/lib/sendmail -t
exit 0
</code>

<p>Some of you might have picked up that the <tt/root.hints/ file is
also available by ftp from Internic.  Please don't use ftp to update
<tt/root.hints/, the above method is much more friendly to the net,
and Internic.

<sect>Migrating to BIND 9

<p>The BIND 9 distribution, and the prepackaged versions too, contains
a document called <tt/migration/ that contains notes about how to
migrate from BIND 8 to BIND 9.  The document is very straight forward.
If you installed binary packages it's likely stored in
<tt>/usr/share/doc/bind*</tt> or <tt>/usr/doc/bind*</tt> somewhere.

<p>If you're running BIND 4, you may find a document called
<tt/migration-4to9/ in the same place.

<sect>Questions and Answers<label id="qanda">

<p>Please read this section before mailing me.

<enum>

  <item>My named wants a named.boot file

  <p>You are reading the wrong HOWTO.  Please see the old version of
  this HOWTO, which covers BIND 4, at <url
  url="http://langfeldt.net/DNS-HOWTO/">

  <item>How do use DNS from inside a firewall? 

  <p>A hint: <tt/forward only;/.  You might also need

  <code>
  query-source port 53;
  </code>

  inside the ``options'' part of the <tt/named.conf/ file as suggested
  in the example <ref id="caching" name="caching"> section.

  <item>How do I make DNS rotate through the available addresses for a
  service, say <tt/www.busy.site/ to obtain a load balancing effect,
  or similar?

  <p>Make several <bf/A/ records for <tt/www.busy.site/ and use BIND
  4.9.3 or later.  Then BIND will round-robin the answers.  It will
  <em/not/ work with earlier versions of BIND.

  <item>I want to set up DNS on a (closed) intranet.  What do I do?

  <p>You drop the <tt/root.hints/ file and just do zone files.  That
  also means you don't have to get new hint files all the time.

  <item>How do I set up a secondary (slave) name server?

  <p>If the primary/master server has address 127.0.0.1 you put a line
  like this in the named.conf file of your secondary:

  <code>
  zone "linux.bogus" {
	type slave;
	file "sz/linux.bogus";
	masters { 127.0.0.1; };
  };
  </code>

  You may list several alternate master servers the zone can be copied
  from inside the <tt/masters/ list, separated by ';' (semicolon).

  <item>I want BIND running when I'm disconnected from the net.  

  <p>There are four items regarding this:

<itemize>

  <item>Specific to BIND 8/9, Adam L Rice has sent me this e-mail, about
  how to run DNS painlessly on a dialup machine:

<tscreen><verb>

I have discovered with newer versions of BIND that this
[<em/shuffeling files, -ed/] is no longer necessary.  There is a
"forward" directive in addition to the "forwarders" directive that
controls how they are used.  The default setting is "forward first",
which first asks each of the forwarders, and then tries the normal
approach of doing the legwork itself if that fails.  This gives the
familiar behaviour of gethostbyname() taking an inordinately long time
when the link is not up.  But if "forward only" is set, then BIND
gives up when it doesn't get a response from the forwarders, and
gethostbyname() returns immediately.  Hence there is no need to
perform sleight-of-hand with files in /etc and restart the server.

In my case, I just added the lines

forward only;
forwarders { 193.133.58.5; };

to the options { } section of my named.conf file. It works very
nicely. The only disadvantage of this is that it reduces an incredibly
sophisticated piece of DNS software to the status of a dumb cache. To
some extent, I would just like to run a dumb cache for DNS instead,
but there doesn't seem to be such a piece of software available for
Linux.
</verb></tscreen>


  <item>I have received this mail from Ian Clark
  &lt;ic@deakin.edu.au&gt; where he explains his way of doing this:

<tscreen><verb>
I run named on my 'Masquerading' machine here. I have 
two root.hints files, one called root.hints.real which contains 
the real root server names and the other called root.hints.fake 
which contains...

----
; root.hints.fake
; this file contains no information
----

When I go off line I copy the root.hints.fake file to root.hints and
restart named.

When I go online I copy root.hints.real to root.hints and restart
named.

This is done from ip-down & ip-up respectively.

The first time I do a query off line on a domain name named doesn't
have details for it puts an entry like this in messages..

Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN

which I can live with.
	 
It certainly seems to work for me. I can use the nameserver for
local machines while off the 'net without the timeout delay for
external domain names and I while on the 'net queries for external
domains work normally

</verb></tscreen>

<p>Peter Denison thought that Ian does not go far enough though.  He
writes:

<tscreen><verb>
When connected)	serve all cached (and local network) entries immediately
		for non-cached entries, forward to my ISPs nameserver
When off-line)	serve local network queries immediately
		fail all other queries **immediately**

The combination of changing the root cache file and forwarding queries
doesn't work.

So, I've set up (with some discussion of this on the local LUG) two nameds
as follows:

named-online:	forwards to ISPs nameserver
		master for localnet zone
		master for localnet reverse zone (1.168.192.in-addr.arpa)
		master for 0.0.127.in-addr.arpa
		listens on port 60053

named-offline:	no forwarding
		"fake" root cache file
		slave for 3 local zones (master is 127.0.0.1:60053)
		listens on port 61053

And combined this with port forwarding, to send port 53 to 61053 when
off-line, and to port 60053 when online. (I'm using the new netfilter
package under 2.3.18, but the old (ipchains) mechanism should work.)

Note that this won't quite work out-of-the-box, as there's a slight bug in
BIND 8.2, which I have logged wth the developers, preventing a slave
having a master on the same IP address (even if a different port). It's a
trivial patch, and should go in soon I hope.
</verb></tscreen>

  <item>I have also received information about how BIND interacts with NFS
  and the portmapper on a mostly offline machine from Karl-Max Wanger:

<tscreen><verb>

I use to run my own named on all my machines which are only
occasionally connected to the Internet by modem. The nameserver only
acts as a cache, it has no area of authority and asks back for
everything at the name servers in the root.cache file. As is usual
with Slackware, it is started before nfsd and mountd.

With one of my machines (a Libretto 30 notebook) I had the problem
that sometimes I could mount it from another system connected to my
local LAN, but most of the time it didn't work.  I had the same effect
regardless of using PLIP, a PCMCIA ethernet card or PPP over a serial
interface.

After some time of guessing and experimenting I found out that
apparently named messed with the process of registration nfsd and
mountd have to carry out with the portmapper upon startup (I start
these daemons at boot time as usual). Starting named after nfsd and
mountd eliminated this problem completely.

As there are no disadvantages to expect from such a modified boot
sequence I'd advise everybody to do it that way to prevent potential
trouble.
</verb></tscreen>

</itemize>

  <item>Where does the caching name server store its cache? Is there
  any way I can control the size of the cache?

  <p>The cache is completely stored in memory, it is <em/not/ written
  to disk at any time.  Every time you kill named the cache is lost.
  The cache is <em/not/ controllable in any way.  named manages it
  according to some simple rules and that is it.  You cannot control
  the cache or the cache size in any way for any reason. If you want
  to you can ``fix'' this by hacking named.  This is however not
  recommended.

  <item>Does named save the cache between restarts?  Can I make it
  save it?

  <p>No, named does <em/not/ save the cache when it dies.  That means
  that the cache must be built anew each time you kill and restart
  named.  There is <em/no/ way to make named save the cache in a file.
  If you want you can ``fix'' this by hacking named.  This is however
  not recommended.

  <item>How can I get a domain? I want to set up my own domain called
  (for example) <tt/linux-rules.net/.  How can I get the domain I want
  assigned to me?

  <p>Please contact your network service provider.  They will be able
  to help you with this.  Please note that in most parts of the world
  you need to pay money to get a domain.

  <item>How can I secure my DNS server?  How do I set up split DNS?

  <p>Both of these are advanced topics.  They are both covered in <url
  url="http://www.etherboy.com/dns/chrootdns.html">.  I will not
  explain the topics further here.

</enum>

<sect>How to become a bigger time DNS admin.<label id="bigger">

<p><bf>Documentation and tools.</bf>

<p>Real Documentation exists.  Online and in print.  The reading of
several of these is required to make the step from small time DNS
admin to a big time one.  

<p>I have written <em/The Concise Guide to DNS and BIND/ (by Nicolai
Langfeldt, me), published by Que (ISBN 0-7897-2273-9).  The book is
much like this HOWTO, just more details, and a lot more of everything.
It has also been translated to Polish and published as <em/DNS i BIND/
by Helion (<url url="http://helion.pl/ksiazki/dnsbin.htm">, ISBN
83-7197-446-9).  Now in 4th edition is <em/DNS and BIND/ by Cricket
Liu and P. Albitz from O'Reilly &amp; Associates (ISBN 0-937175-82-X,
affectionately known as the Cricket book).  Another book is <em/Linux
DNS Server Administration/, by Craig Hunt, published by Sybex (ISBN
0782127363), I have not read it yet.  Another must for good DNS
administration (or good anything for that matter) is <em/Zen and the
Art of Motorcycle Maintenance/ by Robert M. Pirsig.

<p>Online you will find my book, along with tons of other books,
available electronically as a subscription service at <url
url="http://safari.informit.com/">.  There is stuff on <url
url="http://www.dns.net/dnsrd/"> (DNS Resources Directory), <url
url="http://www.isc.org/bind.html">; A FAQ, a reference manual (the
ARM should be enclosed in the BIND distribution as well) as well as
papers and protocol definitions and DNS hacks (these, and most, if not
all, of the RFCs mentioned below, are also contained in the BIND
distribution).  I have not read most of these.  The newsgroup <url
url="news:comp.protocols.tcp-ip.domains"> is about DNS.  In addition
there are a number of RFCs about DNS, the most important are probably
the ones listed here.  Those that have BCP (Best Current Practice)
numbers are <em/highly recommended/.

<descrip>

  <tag/RFC 2671/ P. Vixie, <em/Extension Mechanisms for DNS (EDNS0)/
  August 1999.  

  <tag/RFC 2317/ BCP 20, H. Eidnes et. al. <em/Classless IN-ADDR.ARPA
  delegation/, March 1998. This is about CIDR, or classless subnet
  reverse lookups.

  <tag/RFC 2308/ M. Andrews, <em/Negative Caching of DNS Queries/,
  March 1998.  About negative caching and the $TTL zone file
  directive.

  <tag/RFC 2219/ BCP 17, M. Hamilton and R. Wright, <em/Use of DNS
  Aliases for Network Services/, October 1997.  About
  CNAME usage.

  <tag/RFC 2182/ BCP 16, R. Elz et. al., <em/Selection and Operation
  of Secondary DNS Servers/, July 1997.

  <tag/RFC 2052/ A. Gulbrandsen, P. Vixie, <em/A DNS RR for specifying
  the location of services (DNS SRV)/, October 1996

  <tag/RFC 1918/ Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot,
  E. Lear, <em/Address Allocation for Private Internets/, 02/29/1996.

  <tag/RFC 1912/ D. Barr, <em/Common DNS Operational and Configuration
  Errors/, 02/28/1996.

  <tag/RFC 1912 Errors/ B. Barr <em/Errors in RFC 1912/.  Only
  available at <url
  url="http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html">

  <tag/RFC 1713/ A. Romao, <em/Tools for DNS debugging/, 11/03/1994.

  <tag/RFC 1712/ C. Farrell, M. Schulze, S. Pleitner, D. Baldoni,
  <em/DNS Encoding of Geographical Location/, 11/01/1994.

  <tag/RFC 1183/ R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart,
  <em/New DNS RR Definitions/, 10/08/1990.

  <tag/RFC 1035/ P. Mockapetris, <em/Domain names - implementation and
  specification/, 11/01/1987.

  <tag/RFC 1034/ P. Mockapetris, <em/Domain names - concepts and
  facilities/, 11/01/1987.

  <tag/RFC 1033/ M. Lottor, <em/Domain administrators operations
  guide/, 11/01/1987.

  <tag/RFC 1032/ M. Stahl, <em/Domain administrators guide/,
  11/01/1987.

  <tag/RFC 974/ C. Partridge, <em/Mail routing and the domain system/,
  01/01/1986.

</descrip>
</article>
