mirror of https://github.com/tLDP/LDP
2193 lines
82 KiB
Plaintext
2193 lines
82 KiB
Plaintext
<!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 & 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>
|
||
$<24>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/$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>
|
||
$<24>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#, 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 >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
|
||
<ic@deakin.edu.au> 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 & 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>
|