See RFC 1912 - Common DNS Operational and Configuration Errors
1. A and PTR records
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.
2. Allowed characters between dots
Allowable characters in a label for a host name are only ASCII letters, digits, and the `-' character. Labels may not be all numbers, but may have a leading digit (e.g., 3com.com). Labels must end and begin only with a letter or digit. See [RFC 1035] and [RFC 1123].
3. Name length
Certain operating systems have limitations on the length of their own hostname. While not strictly of issue to the DNS, you should be aware of your operating system's length limits before choosing the name of a host.
4. SOA must have a valid email address. “@” заменяется “.”.
5. Serial number syntax in SOA
The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number
6. Time related SOA arguments
Refresh: How often a secondary will poll the primary server to see
if the serial number for the zone has increased (so it knows
to request a new copy of the data for the zone). Set this to
how long your secondaries can comfortably contain out-of-date
data. You can keep it short (20 mins to 2 hours) if you
aren't worried about a small increase in bandwidth used, or
longer (2-12 hours) if your Internet connection is slow or is
started on demand. Recent BIND versions (4.9.3) have optional
code to automatically notify secondaries that data has
changed, allowing you to set this TTL to a long value (one
day, or more). Retry: If a secondary was unable to contact the primary at the
last refresh, wait the retry value before trying again. This
value isn't as important as others, unless the secondary is on
a distant network from the primary or the primary is more
prone to outages. It's typically some fraction of the refresh
interval. Expire: How long a secondary will still treat its copy of the zone
data as valid if it can't contact the primary. This value
should be greater than how long a major outage would typically
last, and must be greater than the minimum and retry
intervals, to avoid having a secondary expire the data before
it gets a chance to get a new copy. After a zone is expired a
secondary will still continue to try to contact the primary,
but it will no longer provide nameservice for the zone. 2-4
weeks are suggested values. Minimum: The default TTL (time-to-live) for resource records --
how long data will remain in other nameservers' cache. ([RFC
1035] defines this to be the minimum value, but servers seem
to always implement this as the default value) This is by far
the most important timer. Set this as large as is comfortable
given how often you update your nameserver. If you plan to
make major changes, it's a good idea to turn this value down
temporarily beforehand. Then wait the previous minimum value,
make your changes, verify their correctness, and turn this
value back up. 1-5 days are typical values. Remember this
value can be overridden on individual resource records.7. Glue records - “А” records for “NS”
If your nameserver is multi-homed (has more than one IP address), you must list all of its addresses in the glue to avoid cache inconsistency due to differing TTL values, causing some lookups to not find all addresses for your nameserver.
8. CNAME should not be used in MX, NS or in other CNAME.
RFC 974 explicitly states that MX records shall not point to an alias defined by a CNAME.
9. MX record for any host
If you give it an MX record, then the e-mail can be redirected to a real person. Otherwise mail can just sit in a queue for hours or days until the mailer gives up trying to send it. Don't forget that whenever you add an MX record, you need to inform the target mailer if it is to treat the first host as "local". (The "Cw" flag in sendmail, for example
10. Wildcard MX
A wildcard MX will apply only to names in the zone which aren't listed in the DNS at all
11. Authoritation and delegation
You are required to have at least two nameservers for every domain, though more is preferred. Have secondaries outside your network. If the secondary isn't under your control, periodically check up on them and make sure they're getting current zone data from you. Queries to their nameserver about your hosts should always result in an "authoritative" response. If not, this is called a "lame delegation". A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone).
11.1. Parent DNS server must have the same NS records as yours (see also [http://www.isc.org/sw/bind/arm93/Bv9ARM.ch01.html#id2546653 Authoritative Name Servers] in BIND 9 Administrator Reference Manual) You can list servers in the zone's top-level NS records that are not in the parent's NS delegation, but you cannot list servers in the parent's delegation that are not present at the zone's top level.
12. A procedure to fix a serial number that is too large
Take the `incorrect' serial number and add 2147483647 to it. If
the number exceeds 4294967296, subtract 4294967296. Load the
resulting number. Then wait 2 refresh periods to allow the zone
to propagate to all servers. Repeat above until the resulting serial number is less than the
target serial number.Up the serial number to the target serial number.