Some practical advice on DNS zone file construction

For DNS, the OReilly book is probably the nicest and it explains both the easy bits and the subtle things. What follows is a fairly general homily with things that you already know, but just to present a coherent picture.

Some general principles

In theory the DNS is not Internet specific and is not even IP or IPv6 specific, but in practice (with very few exceptions) it is. There can be multiple naming DNS zones (each with a different set of root server) and there can be non-IP RRs, but it is very rare.
In the DNS there is no distinction between “directories” and “files”; each domain name can contain data and/or contain other domain names. Some domain names have both, some have only data (leaf domain names) and some have only subdomains.
In the DNS, all names, whether they have subdomain names or not, are called “domain names”, and there is no such concept as a “host name”; domain names usually name interfaces or sets of interfaces. There is no requirement for a domain name to name interfaces that all belong to the same host, for example.
The delegation records define a hierarchy for resolving domains, and the zone transfers define a hierarchy for authority. The two need not be similar. If server A for domain X delegates to server B for domain Y, there need not be any authority relationship between A and B, and viceversa if server I gets a zone from server J, there is no need for I to delegate anything to J.

Zones and zone files

A zone is a subset of the DNS that is served by the same DNS server, and may include none, some or all of the subdomains of a domain (that is it includes all subdomains of the root domain of the zone that are defined and are not delegated).
While a zone is a DNS concept, a zone file is purely a DNS server specific entity (even if most servers use mostly compatible syntax for zone files) and can describe many subdomain subtrees (if the zone encompasses them); there is no requirement for each subdomain to be split off into a separate zone file (e.g. via $INCLUDE).
Zone files represent zones but are not zones. They contain some constructs and conventions that are shorthands, and do not exists in the DNS, like most directives beginning with $ and things like @ pseudo-domain names and “blank” domain names, and the use of "." as the last component of a domain name to mean it is absolute.
“RR” for resource record is usually used to mean either the actual DNS resource records or more commonly the line representing that RR in the zone file.
A “glue” RR is one that is inside a zone but carries data from outside the zone, data is needed to resolve information about a domain in the zone. For example an A RR that defines the address of the target of an NS record. Unnecessary glue records are as a rule a very bad idea. A zone(file) should as far as possible only contain RRs about domains in that zone[file] or glue required by that zone. Some DNS server packages check this.

My guidelines for writing zone files

General principles:

The parent zone must delegate to authoritative name servers:
```
$ORIGIN com.
....
example         NS      A.example.com.
example         NS      B.example.com.
```
A and B must be authoritative for example.com.
The NS records in the delegated zone must include those in the parent zone:
```
$ORIGIN example.com.
....
@               NS      A.example.com.
@               NS      B.example.com.
@               NS      C.example.com.
```
Other authoritative servers like C may be added to the list, but it is not necessary.
A DNS server is authoritative if it resolves queries from a copy of the zone (not necessarily of the zone file), not by querying other servers.
An authoritative name server is a slave if it obtains the zone by AXFR (zone transfer) or equivalent from another authoritative server, and it is a master if the zone is just there (usually then as a zone file, but it could be a MySQL database or whatever).
In theory propagating copies of the zone could be done by non DNS protocols, like copying the zone file by FTP or RSYNC, but this is rare and can be error prone.
There is no rule that requires one of the delegated servers for a zone to be the master, but they must all be authoritative. A delegated server that is not authoritative is called “lame”.

Specifically about RRs (resource records, represented by lines inside a zone file):

The SOA RR must contain the name of an authoritative server from which other (authorized) authoritative servers can AXFR the zone. As a rule this should be the name of the master server.
Any RR for the zone itself (first column @ or equivalent) cannot be a CNAME.
The target (last field) for an NS RR cannot be a CNAME and cannot be an IP address.
The target (last field) for an MX RR cannot be a CNAME and cannot be an IP address.
If a domain name has a CNAME RR it cannot have any other RR, because it must be an exact synonym for the domain name it is CNAMEd to, and one cannot superset or override the RRs for the target domain.
The target of a CNAME should not be another CNAMEd domain; that is there cannot be chains of CNAMEs. This can be difficult to avoid in practice and violating this rule is not so bad.
There are some restrictions on the timeout values in the SOA RR, but any sensible values will not violate them.
A subdomain cannot be split in two zone files, using $INCLUDE to achieve an equivalent effect is often not a good idea.

Some personal style recommendations

I name zone files after the domain name of the zone, but with the components in natural order, not in the inverted order that unfortunately has been adopted for the DNS. That is, as US.CA.SF.dotCom.garage if the domain name for the zone is garage.dotCom.SF.CA.US. The reason for this is that the inverted order unfortunately used by the DNS for domains makes them hard to sort in a meaningful way.
It is very important to remember to terminate right hand side target domain names with . to ensure they are understood as absolute unless they do refer to domains in the zone file.
It is a very bad practice to leave the first field of an RR blank to mean “same as the previous line”. This makes the zone file unsortable. The first field should be either @ or a verbatim repetition of the field in the previous line.
Using $ORIGIN makes non absolute domain names belong to the specified zone explicitly, and means that one cannot share a zone file between two zones, which instead is often desirable.
That RR lines involving NS and MX cannot target IP addresses means that in practice their targets must be A/AAAA RRs. The no-CNAME restriction is often not enforced, and the symbolic name only one sometimes is not enforced.
I prefer to specify a default TTL with $TTL than put one on every RR or take whatever default is assumed by BIND.
An RP for a subdomain is not necessary, but some ISPs/services require it (mostly for weak antispam reasons).
For each domain I have a standard set of subdomains that denote the server for a particular protocol, for example: DNS, SMTP, POP3, FTP, WWW.
There are many less common but useful RR types, like TXT, RP, LOC, SRV, ... and some obscure practices especially concerning reverse DNS mappings that I do out of a sense of historical style or for geek value but are not necessary. They are often only explained in the OReilly book on DNS.
Using wildcard left hand side domain name is fraught with danger, and in particular that can be risky with MX records and there is any other RR for them. I do something like that, but it is for carefully calculated reasons and for very great benefit.
I try diligently to have zone-local (“in-bailiwick”) glue records as recommended for very good reasons in this reference, but this cannot always be done exactly. In particular because of the Gradwell servers. Entirely zone-local glue RRs impose a higher burdern of maintenance. The author insists that this is not a problem as it can and should be automated but usually DNS servers make you do that manually (IIRC including the one he wrote).

Some example zone files

A simple forward domain

; -*- outline-regexp: ";;* " -*- vim:ft=bindzone 
$TTL            1H
@                       SOA     DNS hostmaster (
                                  ;serial       refresh retry   expire  negTTL
                                  2004022300    1H      30M     20D     1H
;                                 YYYYmmDDnn
                                )
@                       RP      root rp
@                       TXT     "Zone for example.org"
rp                      TXT     "example.org hostmaster"
;
; '@', name servers and mail exchangers cannot be 'CNAME's.
;
@                       NS      DNS
;
@                       MX 1    SMTP
;
@                       A       IPaddress
;
DNS                     A       IPaddress
SMTP                    A       IPaddress
;
POP3                    CNAME   @
WWW                     CNAME   @
FTP                     CNAME   @
;
; Anti-SPAM domains.
;
remove-this             TXT     "This is a spamtrap subdomain. Remove it from email addresses."
;
; Recipient-specific domains.
;
*.to                    MX 1    SMTP
*.to                    MX 99   MXbackup.Gradwell.net.
*.for                   MX 1    SMTP
*.for                   MX 99   MXbackup.Gradwell.net.

A more complete forward domain

; -*- outline-regexp: ";;* " -*- vim:ft=bindzone
$TTL            1H
@                       SOA     DNS hostmaster (
                                  ;serial       refresh retry   expire  negTTL
                                  2004060900    1H      30M     20D     1H
;                                 YYYYmmDDnn
                                )
@                       RP      root rp
@                       TXT     "Zone for example.com"
rp                      TXT     "example.com hostmaster"
@                       LOC     52 14 05 N 00 08 50 E 50m
;
; '@', name servers and mail exchangers cannot be 'CNAME's.
;
@                       NS      ns1.Gradwell.net.
@                       NS      ns2.Gradwell.net.
@                       NS      DNS
;
hq                      NS      DNS
;
@                       MX 10   @
@                       MX 20   SMTP
@                       MX 30   SMTP2
@                       MX 99   MXbackup.Gradwell.net.
;
@                       A       IPaddress
IP6                     AAAA    IPv6address
;
DNS                     A       IPaddress
DNS.IP6                 AAAA    IPv6address
SMTP                    A       IPaddress
SMTP.IP6                AAAA    IPv6address
SMTP2                   A       IPaddress
SMTP2.IP6               AAAA    IPv6address
;
POP3                    CNAME   @
POP3.IP6                CNAME   IP6
WWW                     CNAME   @
WWW.IP6                 CNAME   IP6
FTP                     CNAME   @
FTP.IP6                 CNAME   IP6
SSL                     CNAME   @
SSL.IP6                 CNAME   IP6
H323                    CNAME   @
H323.IP6                CNAME   IP6
SIP                     CNAME   @
SIP.IP6                 CNAME   IP6
;
; The IPv6 network is 2001:0618:0400:b4eb::/64.
gw.IP6                  AAAA    IPv6address
net.IP6                 AAAA    IPv6prefix::
net.IP6                 PTR     IPv6reversemap.IP6.ARPA.
net.IP6                 PTR     IPv6reversemap.IP6.INT.
sm.IP6                  AAAA    ffff:ffff:ffff:ffff::
;
; Anti-SPAM domains.
;
0406.exp                TXT     "This subdomain loses its MX RR sometime after Jun 2004"
0406.exp                MX 1    SMTP
;
remove-this             TXT     "This is a spamtrap subdomain. Remove it from email addresses."
;
; Recipient-specific domains. Remember special rules about '*'.
;
*.to                    MX 1    SMTP
*.to                    MX 99   MXbackup.Gradwell.net.
*.for                   MX 1    SMTP
*.for                   MX 99   MXbackup.Gradwell.net.
;
; Dynamic subzone.
;
;dyn                    NS      @

One might want to add a section for listing services:

;
;domain [ttl]           IN NAPTR order preference flags service regexp target
@                       NAPTR   0 0 "s" "DNS+D2U"       "" _dns._udp
@                       NAPTR   0 0 "s" "DNS+D2T"       "" _dns._tcp
@                       NAPTR   0 0 "s" "SMTP+D2T"      "" _pop3._tcp
@                       NAPTR   0 0 "s" "SSMTP+D2T"     "" _ssmtp._tcp
@                       NAPTR   0 0 "s" "POP3+D2T"      "" _pop3._tcp
@                       NAPTR   0 0 "s" "POP3+D2T"      "" _pop3._tcp
@                       NAPTR   0 0 "s" "POP3S+D2T"     "" _pop3s._tcp
@                       NAPTR   0 0 "s" "HTTP+D2T"      "" _http._tcp
@                       NAPTR   0 0 "s" "HTTPS+D2T"     "" _https._tcp
@                       NAPTR   0 0 "s" "FTP+D2T"       "" _ftp._tcp
@                       NAPTR   0 0 "s" "H323+D2T"      "" _h323._tcp
@                       NAPTR   0 0 "s" "SIPS+D2T"      "" _sips._tcp
@                       NAPTR   1 0 "s" "SIP+D2T"       "" _sip._tcp
@                       NAPTR   2 0 "s" "SIP+D2U"       "" _sip._udp
;
;_service._proto.name   SRV     prio weight     port    target
_dns._udp               SRV     1 10            53      DNS
_dns._tcp               SRV     1 10            53      DNS
_smtp._tcp              SRV     1 10            25      POP3
_ssmtp._tls             SRV     1 10            465     SSL
_pop3._tcp              SRV     1 10            110     POP3
_pop3s._tls             SRV     1 10            995     SSL
_http._tcp              SRV     1 10            80      WWW
_https._tls             SRV     1 10            443     SSL
_ftp._tcp               SRV     1 10            21      FTP
_h323._tcp              SRV     1 10            1720    H323
_sips._tcp              SRV     1 10            5060    SIP
_sip._tcp               SRV     1 10            5060    SIP
_sip._udp               SRV     1 10            5060    SIP

The services above are generic ones. For a list of (some) of the names used for Microsoft AD compatibility, check the Samba Network Browsing HOWTO.

Some practical advice onDNS zone file construction

Some practical advice on
DNS zone file construction