d6da9453b6
This has most of the non-essential stuff removed (ie: what is not built) bmake glue to follow.
173 lines
7.1 KiB
Plaintext
173 lines
7.1 KiB
Plaintext
Path: vixie!vixie
|
|
From: vixie@vix.com (Paul A Vixie)
|
|
Newsgroups: comp.protocols.tcp-ip.domains
|
|
Subject: Re: Format of DNS files (style question)
|
|
Date: 28 Aug 94 03:17:08
|
|
Organization: Vixie Enterprises
|
|
Lines: 159
|
|
Distribution: inet
|
|
Message-ID: <VIXIE.94Aug28031708@office.home.vix.com>
|
|
References: <33onnr$i4u@zombie.ncsc.mil>
|
|
NNTP-Posting-Host: office.home.vix.com
|
|
In-reply-to: sjr@zombie.ncsc.mil's message of 27 Aug 1994 21:02:51 -0400
|
|
|
|
> (Style) Suggestions for how to layout DNS configuration files (both
|
|
> forward and reverse)?
|
|
|
|
I've gone back and forth on the question of whether the BOG should include a
|
|
section on this topic. I know what I myself prefer, but I'm wary of ramming
|
|
my own stylistic preferences down the throat of every BOG reader. But since
|
|
you ask :-)...
|
|
|
|
Create /var/named. If your system is too old to have a /var, either create
|
|
one or use /usr/local/adm/named instead. Put your named.boot in it, and make
|
|
/etc/named.boot a symlink to it. If your system doesn't have symlinks, you're
|
|
S-O-L (but you knew that). In named.boot, put a "directory" directive that
|
|
specifies your actual BIND working directory:
|
|
|
|
directory /var/named
|
|
|
|
All relative pathnames used in "primary", "secondary", and "cache" directives
|
|
will be evaluated relative to this directory. Create two subdirectories,
|
|
/var/named/pri and /var/named/sec. Whenever you add a "primary" directive
|
|
to your named.boot, use "pri/WHATEVER" as the path name. And then put the
|
|
primary zone file into "pri/WHATEVER". Likewise when you add "secondary"
|
|
directives, use "sec/WHATEVER" and BIND (really named-xfer) will create the
|
|
files in that subdirectory.
|
|
|
|
(Variations: (1) make a midlevel directory "zones" and put "pri" and "sec"
|
|
into it; (2) if you tend to pick up a lot of secondaries from a few hosts,
|
|
group them together in their own subdirectories -- something like
|
|
/var/named/zones/uucp if you're a UUCP Project name server.)
|
|
|
|
For your forward files, name them after the zone. dec.com becomes
|
|
"/var/named/zones/pri/dec.com". For your reverse files, name them after the
|
|
network number. 0.1.16.in-addr.arpa becomes "/var/named/zones/pri/16.1.0".
|
|
|
|
When creating or maintaining primary zone files, try to use the same SOA
|
|
values everywhere, except for the serial number which varies per zone. Put
|
|
a $ORIGIN directive at the top of the primary zone file, not because it's
|
|
needed (it's not since the default origin is the zone named in the "primary"
|
|
directive) but because it make it easier to remember what you're working on
|
|
when you have a lot of primary zones. Put some comments up there indicating
|
|
contact information for the real owner if you're proxying. Use RCS and put
|
|
the "$Id: style.txt,v 8.1 1995/12/22 21:59:52 vixie Exp $" in a ";" comment near the top of the zone file.
|
|
|
|
The SOA and other top level information should all be listed together. But
|
|
don't put IN on every line, it defaults nicely. For example:
|
|
|
|
==============
|
|
@ IN SOA gw.home.vix.com. postmaster.vix.com. (
|
|
1994082501 ; serial
|
|
3600 ; refresh (1 hour)
|
|
1800 ; retry (30 mins)
|
|
604800 ; expire (7 days)
|
|
3600 ) ; minimum (1 hour)
|
|
|
|
NS gw.home.vix.com.
|
|
NS ns.uu.net.
|
|
NS uucp-gw-1.pa.dec.com.
|
|
NS uucp-gw-2.pa.dec.com.
|
|
|
|
MX 10 gw.home.vix.com.
|
|
MX 20 uucp-gw-1.pa.dec.com.
|
|
MX 20 uucp-gw-1.pa.dec.com.
|
|
==============
|
|
|
|
I don't necessarily recommend those SOA values. Not every zone is as volatile
|
|
as the example shown. I do recommend that serial number format; it's in date
|
|
format with a 2-digit per-day revision number. This format will last us until
|
|
2147 A.D. at which point I expect a better solution will have been found :-).
|
|
(Note that it would last until 4294 A.D. except that there are some old BINDs
|
|
out there that use a signed quantity for representing serial number interally;
|
|
I suppose that as long as none of these are still running after 2047 A.D.,
|
|
that we can use the above serial number format until 4294 A.D., at which point
|
|
a better solution will HAVE to be found.)
|
|
|
|
You'll note that I use a tab stop for "IN" even though I never again specify
|
|
it. This leaves room for names longer than 7 bytes without messing up the
|
|
columns. You might also note that I've put the MX priority and destination
|
|
in the same tab stop; this is because both are part of the RRdata and both
|
|
are very different from MX which is an RRtype. Some folks seem to prefer to
|
|
group "MX" and the priority together in one tab stop. While this looks neat
|
|
it's very confusing to newcomers and for them it violates the law of least
|
|
astonishment.
|
|
|
|
If you have a multi-level zone (one which contains names that have dots in
|
|
them), you can use additional $ORIGIN statements but I recommend against it
|
|
since there is no "back" operator. That is, given the above example you can
|
|
add:
|
|
|
|
=============
|
|
$ORIGIN home
|
|
gw A 192.5.5.1
|
|
=============
|
|
|
|
The problem with this is that subsequent RR's had better be somewhere under
|
|
the "home.vix.com" name or else the $ORIGIN that introduces them will have
|
|
to use a fully qualified name. FQDN $ORIGIN's aren't bad and I won't be mad
|
|
if you use them. Unqualified ones as shown above are real trouble. I usually
|
|
stay away from them and just put the whole name in:
|
|
|
|
=============
|
|
gw.home A 192.5.5.1
|
|
=============
|
|
|
|
In your reverse zones, you're usually in some good luck because the owner name
|
|
is usually a single short token or sometimes two.
|
|
|
|
=============
|
|
$ORIGIN 5.5.192.in-addr.arpa.
|
|
@ IN SOA ...
|
|
NS ...
|
|
1 PTR gw.home.vix.com.
|
|
-------------
|
|
$ORIGIN 1.16.in-addr.arpa.
|
|
@ IN SOA ...
|
|
NS ...
|
|
2.0 PTR gatekeeper.dec.com.
|
|
=============
|
|
|
|
It is usually pretty hard to keep your forward and reverse zones in synch.
|
|
You can avoid that whole problem by just using "h2n" (see the ORA book, DNS
|
|
and BIND, and its sample toolkit, included in the BIND distribution or on
|
|
ftp.uu.net (use the QUOTE SITE EXEC INDEX command there to find this -- I
|
|
never can remember where it's at). "h2n" and many tools like it can just
|
|
read your old /etc/hosts file and churn it into DNS zone files. (May I
|
|
recommend contrib/decwrl/mkdb.pl from the BIND distribution?) However, if
|
|
you (like me) prefer to edit these things by hand, you need to follow the
|
|
simple convention of making all of your holes consistent. If you use
|
|
192.5.5.1 and 192.5.5.3 but not (yet) 192.5.5.2, then in your forward file
|
|
you will have something like
|
|
|
|
=============
|
|
...
|
|
gw.home A 192.5.5.1
|
|
;avail A 192.5.5.2
|
|
pc.home A 192.5.5.3
|
|
=============
|
|
|
|
and in your reverse file you will have something like
|
|
|
|
=============
|
|
...
|
|
1 PTR gw.home.vix.com.
|
|
;2 PTR avail
|
|
3 PTR pc.home.vix.com.
|
|
=============
|
|
|
|
This convention will allow you to keep your sanity and make fewer errors.
|
|
Any kind of automation (h2n, mkdb, or your own perl/tcl/awk/python tools)
|
|
will help you maintain a consistent universe even if it's also a complex
|
|
one. Editing by hand doesn't have to be deadly but you MUST take care.
|
|
|
|
Anyone who wants to know how to maintain nonleaf zones, i.e., zones which
|
|
have few or no hosts in them but have hundreds or thousands of delegations,
|
|
should attend Usenix LISA in San Diego and be there for the SENDS talk.
|
|
Contact office@usenix.org for conference information.
|
|
--
|
|
Paul Vixie
|
|
Redwood City, CA
|
|
decwrl!vixie!paul
|
|
<paul@vix.com>
|