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