The order of the fields is always the same; however, the first two are optional (as indicated by the brackets), and the contents of the last vary according to the record-type field.
The first field is the name of the domain that applies to the record. If this field is left blank in a given RR, it defaults to the name of the previous RR.
A domain name in a zone file can be either a fully qualified name, terminated with a dot, or a relative name, in which case the current domain is appended to it.
The second field is an optional time-to-live field. This specifies how long (in seconds) this data will be cached in the database before it is disregarded and new information is requested from a server. By leaving this field blank, the ttl defaults to the minimum time specified in the Start-Of-Authority (SOA) resource record.
If the ttl value is set too low, the server will incur a lot of repeat requests for data refreshment; if, on the other hand, the ttl value is set too high, changes in the information will not be timely distributed.
Most ttl values should be initially set to between a day (86400) and a week (604800). Then, depending on the frequency of actual change of the information, you can change the appropriate ttl values to reflect that frequency. Also, if you have some ttl values that have very high numbers because you know they relate to data that rarely changes. When you know that the data is now about to change, reset the ttl to a low value (3600 to 86400) until the change takes place. Then change it back to the original high value.
All RR's with the same name, class, and type should have the same ttl value.
The third field is the record class. Only one class is currently in use: IN for the TCP/IP protocol family.
The fourth field states the resource record type. There are many types of RR's; the most commonly used types are discussed in Resource Record Types.
The contents of the record-specific-data field depend on the type of the particular resource record.
Although case is preserved in names and data fields when loaded into the name server, all comparisons and lookups in the name server database are case insensitive. However, this situation might change in the future; thus, you should be consistent in your use of lower and uppercase.