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.

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.

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.

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”.

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).