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: 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