diff options
Diffstat (limited to 'contrib/bind/doc/misc/style.txt')
| -rw-r--r-- | contrib/bind/doc/misc/style.txt | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/contrib/bind/doc/misc/style.txt b/contrib/bind/doc/misc/style.txt new file mode 100644 index 0000000..a966066 --- /dev/null +++ b/contrib/bind/doc/misc/style.txt @@ -0,0 +1,172 @@ +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> |
